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Introdução 


Esse livro tem como objetivo principal fornecer conhecimentos sobre o 
processo de gerenciamento de projetos públicos. Espero que ele ajude-o 
a ter uma experiência agradável, empolgante e bem-sucedida na com- 
preensão do que é um projeto público e como o mesmo deve ser ge- 
renciado. A abordagem aqui apresentada tentou identificar as melhores 
práticas utilizadas para um bom gerenciamento de projetos. 


O livro está organizado em cinco capítulos. O capítulo 1 apresenta al- 
guns conceitos iniciais sobre o que é um projeto e quais são as caracte- 
rísticas que diferenciam a atividade de projetos das atividades cotidianas 
e rotineiras das organizações. 


O capítulo 2 apresenta as principais metodologias para gerenciamento 
de projetos utilizados pelas organizações públicas e privadas na atualida- 
de. Apresenta um breve resumo das principais metodologias. Apresenta 
o PMI, o SCRUM, dentre outras metodologias. 


O capítulo 3 apresenta as fases de desenvolvimento de um projeto, to- 
mando como base o Guia do Conhecimento em Gerenciamento de Pro- 
jetos (Guia PMBOKQ), Quinta edição. O ponto de partida é dado pela 
apresentação dos processos de iniciação, passando pelos processos de 
planejamento, execução e controle do projeto. Finaliza-se esse capítulo 
apresentando os processos de encerramento de um projeto. 


O capítulo 4 apresenta as principais estruturas utilizadas para o gerencia- 
mento dos projetos. Apresenta as três estruturas principais e no final os 
escritórios de gerenciamento de projetos (EGP) ou Project Management 
Office (PMO). 


O capítulo 5 apresenta alguns dos principais softwares utilizados para o 
gerenciamento de projetos. 


O gerenciamento de projetos, como todos os outros aspectos da vida, 
está em constante mudança e desenvolvimento, de modo que, para um 
livro permanecer relevante, ele inevitavelmente precisa ser atualizado 
periodicamente para refletir essas mudanças. O que tentamos fazer aqui 
foi uma versão mais atualizada dos principais processos e ferramentas 
que podem ser utilizadas para realizar o gerenciamento de projetos. 


O livro Gestão de Projetos Públicos foi escrito para proporcionar a seus 
leitores duas coisas principais: a explicação de conceitos e técnicas e a 
enumeração de exemplos que mostrem como eles podem ser aplicados 
de forma eficaz. Embora trate justamente de coisas práticas que os leito- 
res devem saber para prosperar em um ambiente de projeto, o livro não 
abandona a aprendizagem real; ele simplesmente desafia os leitores a 
pensar criticamente sobre os princípios de gestão de projetos e a aplicá- 
-los no contexto do mundo real. 


Vale ressaltar que, como Administrador Público, o profissional que atua 
na execução de projetos públicos deve seguir os princípios da adminis- 
tração pública que são: 


a) legalidade: como o firme compromisso com o ordenamento jurídico 
e a observância dos atos normativos que o constituem; 


b) impessoalidade: como o dever de agir de modo imparcial perante 
terceiros, sem discriminações, distinções ou preferências; 


c) moralidade: como a obrigação de pautar as ações não apenas pela 
lei, mas também pela boa-fé, lealdade e probidade, evitando desvios 
de finalidade ou abusos de poder; 


d) publicidade e transparência: como a obrigação de tornar públicos e 
abertos dados, informações e ações, disponibilizando-os de maneira 
acessível à população; 


e) eficiência: como a qualidade de quem realiza de maneira diligente as 
suas funções, alcançando a melhor relação entre recursos emprega- 
dos e resultados obtidos. 


Além disso, considero importante enfatizar que, além desses princípios, 
o Administrador Público que irá atuar na condução de projetos públicos 
deve como preceito seguir três regras básicas de comportamento: a) fa- 
zer sempre o que é certo e justo mesmo que isto seja o mais trabalhoso 
e difícil e mesmo quando ninguém esteja olhando; b) tratar os outros 
com empatia, evidenciando o padrão de comportamento com o qual o 
próprio servidor gostaria de ser tratado; e c) reconhecer, por meio de 
suas atitudes, que o orçamento da União, Estados e Municípios e os 
valores por elas despendidos têm origem no esforço de cada cidadão 
brasileiro e, por isso, deve ser aplicado com a máxima responsabilidade 
e economicidade. 


Bons estudos! 


Professor Ricardo Thielmann 


Objetivo Geral 


Fornecer ao aluno os conceitos para uma boa gestão de projetos e apro- 
fundar a discussão de temas relativos à gestão de projetos. 


Objetivos Específicos 
* Examinar a natureza dos projetos e do gerenciamento de projetos; 


* Fornecer ao aluno uma terminologia comum sobre o tema gestão de 
projetos para discussões sobre o tema; 


* Examinar o ambiente onde os projetos acontecem; 


* Definir como os projetos podem ser definidos em termos de seus 
objetivos, seu escopo e estratégia para o seu complemento; 


* | Examinar como os projetos são planejados e controlados; 


* Examinar os instrumentos informatizados para gestão de projetos. 


Ementa 


O sistema de planejamento e acompanhamento de projeto. Estruturas 
organizacionais de projeto. Ciclos e fases do projeto. Definição das áreas 
de conhecimento do projeto: escopo, tempo, custos, qualidade, recursos 
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ção do projeto. Identificação de restrições. Definição dos controles de 
planejamento do projeto. Avaliação da eficiência, eficácia e efetividade. 
Técnicas de planejamento, programação e controle de projetos (técnicas 
de redes, PERT/CPM, ROY, cronogramas etc.). Avaliação econômica e 
social de projetos. Softwares para o gerenciamento de projetos. 
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CAPÍTULO | 


CONCEITOS INICIAIS 


Prof. Ricardo Thielmann 


Objetivos Específicos 


O objetivo principal deste capítulo 1 é fornecer ao aluno um conjunto de 
conceitos que possam padronizar a linguagem relacionada à atividade de 
projetos. Além disso, procurar-se-á evidenciar as restrições-chaves den- 
tro das quais o projeto deve ser gerido. Será apresentado o ciclo de vida 
dos projetos e a definição do que é gestão de projetos. Serão apresenta- 
dos, também, os conceitos sobre o que é um projeto público e onde ele 
está inserido no desenvolvimento das políticas públicas. 


Introdução 


A atividade de desenvolvimento de projetos não é uma temática nova. 
Quando se olha para um passado muito distante, verifica-se que os 
projetos já são desenvolvidos de forma planejada desde tempos muito 
antigos. Alguns exemplos na história nos apontam que a humanidade, 
através de seus estudiosos (arquitetos do antigo Egito, como exemplo), 
pensou na construção de estruturas, que até hoje criam impacto e per- 
plexidade nas pessoas. Um bom exemplo desses projetos é a Grande 
Pirâmide de Degraus de Saqgara, também conhecida como Pirâmide de 
Djoser ou Pirâmide de Saggara!, erguida para o sepultamento do Faraó 
Djoser por seu vizir Imhotep. Construída durante o século XXVII a.C. 
na necrópole de Saqgara, no nordeste da cidade de Mênfis, é o edifício 
central de um grande complexo mortuário num amplo pátio, cercado por 
estruturas e elementos decorativos cerimoniais. 


1 Para maiores detalhes sobre a Pirâmide de Degraus de Saqqgara veja o vídeo “Pirâmide de Saqgara 
- Pirâmides do Egito - Restauração - Mistérios - Interior da Pirâmide” disponível em https://youtu. 
be/ABzxkabE7fY 
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Figura 1 - Pirâmide de Degraus de Saqgara, Egito. 

Fonte: Ministério de Antiguidades do Egito. Acesso: https://aventurasnahistoria.uol.com.br/ 
noticias/historia-hoje/governo-egipcio-conclui-reforma-da-piramide-de-djoser-confira-ima- 
gens-divulgadas.phtml 


Essa grande estrutura exigiu um processo de planejamento que, até para 
os dias atuais, surpreende pelo seu nível de complexidade, ainda mais 
quando pensamos que esse grande projeto foi feito há mais de 4.000 
anos. Essa obra envolveu a disponibilização de vários recursos materiais 
(pedras, madeira, argila), pessoais (escravos, escribas, arquitetos, dentre 
outros) e animais (cavalos, gado, elefantes). Envolveu a necessidade de 
programação e desenvolvimento de uma sequência de atividades para a 
sua realização. 


Sun Tzu? escreveu sobre programação e estratégia há 2.500 anos, de 
uma perspectiva militar. 


Nenhuma dessas atividades poderia ter sido realizada sem algum tipo de 
programação; ou seja, a compreensão das atividades e o seu sequencia- 
mento. No entanto, embora se acredite que os gerentes, padres e líde- 
res militares, que controlavam as organizações responsáveis por realizar 
essas obras, deveriam ter um conhecimento de programação (ou pelo 
menos os bem-sucedidos teriam), há poucas evidências de processos 
formais até o século XVIII. Então, pode-se dizer que as atividades de pro- 
jetos remontam a tempos muito antigos. 


Dando um salto e posicionando a argumentação nos dias atuais, as ativi- 
dades de projetos tornaram-se uma disciplina, formalmente estudada, a 


2 Sun Tzu foi um general chinês conhecido por suas vitórias durante os períodos de guerra, por 
volta de 400 a.C. Inspirado em sua experiência, ele escreveu “The Art of War”, um livro clássico de 
estratégia militar. O livro foi traduzido para o francês por um missionário jesuíta e acredita-se que 
Napoleão Bonaparte o leu. Ao longo da história, muitas operações militares bem-sucedidas foram 
baseadas nas ideias de Sun Tzu, incluindo Genghis Khan, as legiões romanas e até mesmo as tropas 
de Norman Schwarzkopf na Guerra do Golfo. 


partir da década de 20, do século XX. Um grande impulso foi dado com 
o advento do Gráfico de Gantt? e seu uso como ferramenta para planeja- 
mento do tempo de execução de projetos. 


E atualmente, século XXI, a gestão de projetos tornou-se alvo de inúme- 
ros estudos, uma vez que os projetos estão se tornando cada vez mais 
complexos e têm assumido posições estratégicas para o sucesso das or- 
ganizações mais inovadoras. 


Isso se deve, principalmente, à necessidade que as organizações têm de 
dar respostas rápidas às tendências de um mercado cada vez mais ávido 
por inovações. 


Então, gerenciar um projeto é aplicar conhecimentos, habilidades, infor- 
mações, técnicas e experiências para desenvolver atividades relaciona- 
das a um conjunto de objetivos pré-definidos, com restrições de tempo, 
orçamento e qualidade, utilizando-se de recursos humanos e tecnologias 
(THIELMANN e SILVA, 2014). 


Hoje, com a rapidez como ocorrem as mudanças nas rotinas de traba- 
lho, as organizações estão executando cada vez mais projetos no seu 
dia a dia. Os mercados estão cada vez mais globalizados e, portanto, 
mais competitivos, fazendo surgir a necessidade de as organizações 
buscarem melhores práticas para entregar produtos e serviços com o 
maior valor agregado possível, no menor tempo possível a seus clien- 
tes. Devido a este crescimento da competitividade, somado à clientela 
cada vez mais exigente e aos constantes avanços tecnológicos, tem-se 
um cenário em que é fundamental a gestão eficaz de projetos, cujos 
prazos são cada vez menores e os recursos cada vez mais escassos 
(THIELMANN e SILVA, 2014). 


3 O Gráfico de Gantt é um gráfico que representa o cronograma através de uma sequência de barras 
que indicam a duração de cada atividade do projeto. O paralelismo entre as atividades é facilmente 
visualizado. À medida que as atividades são executadas, as barras correspondentes vão sendo colo- 
ridas. O seu uso inicial remonta ao Harmonygraph de Adamiecki. Karol Adamiecki, um economista 
polonês, engenheiro e pesquisador de gestão, desenvolveu o Harmonograma (ou Harmonygraph) 
em 1896. O Harmonygraph de Adamiecki tem uma escala de datas no eixo vertical (lado esquer- 
do) e lista as atividades na parte superior. Cada atividade era representada por uma tira de papel 
em escala, e o cronograma atual e a duração das atividades eram representados pela posição e 
comprimento das tiras. No cabeçalho, acima das tiras, o nome e a duração da atividade e a lista 
de atividades anteriores são mostrados. As faixas que representam as atividades precedentes estão 
sempre à esquerda da faixa do sucessor. A tabulação de cada atividade predecessora e sucessora 
no Harmonygraph ('de” e “para”, torna-o um predecessor dos sistemas CPM e PERT, que foram de- 
senvolvidos a partir da década de 60. O gráfico de Gantt pode ser considerado um aperfeiçoamento 
do Harmonygraph, a partir do momento que o objetivo principal do Harmonygraph é mostrar quais 
atividades estão planejadas para serem realizadas e seu tempo no futuro (o sequenciamento só pode 
ser inferido), o Gráfico de Gantt tende a ser retrospectivo e diagnóstico, quanto compara o trabalho 
planejado com o trabalho executado. 
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1.1 O Projeto 
1.1.1 O Que é um Projeto? 


As organizações executam trabalho. O trabalho envolve atividades con- 
tinuadas e/ou atividades de projetos, embora possa existir superposição 
entre os dois. Atividades continuadas e atividades de projetos possuem 
muitas características comuns, por exemplo, ambos são: 


* executados por pessoas, 
* restringidos por recursos limitados, 
* planejados, executados e controlados. 


As atividades continuadas incluem o desenvolvimento e a gestão das orga- 
nizações de produção e serviços, bem como o desempenho eficiente das 
tarefas ordinárias. Em contrapartida, as atividades de projetos estão focadas 
no desenvolvimento, gestão e execução de tarefas extraordinárias, limita- 
das no tempo e, em termos de seu conteúdo, geram resultados únicos. 


As atividades continuadas e de projetos diferem, principalmente, porque, 
enquanto as primeiras são contínuas e repetitivas, os projetos são tem- 
porários e únicos. Assim, um projeto pode ser definido em termos de 
suas características distintas — um projeto é um empreendimento tem- 
porário com o objetivo de criar um produto ou serviço único, conforme 
demonstrado na Figura 2. Temporário significa que cada projeto tem um 
começo e um fim bem definidos. Único significa que o produto ou serviço 
produzido é de alguma forma diferente de todos os outros produtos ou 
serviços semelhantes. Os projetos são desenvolvidos em todos os níveis 
da organização. Eles podem envolver uma única pessoa ou milhares de- 
las. Podem requerer menos de 100 horas de trabalho ou até 10.000.000 
ou mais para se completarem. Os projetos podem envolver uma unidade 
isolada da organização ou atravessar as fronteiras organizacionais, como 
ocorre com consórcios e parcerias. Os projetos são frequentemente com- 
ponentes críticos da estratégia de negócios da organização. 


Todo projeto tem o produto ou É 
PÇA serviço resultante é 
início e fim Ê 

diferente de todos 


definidos eni j 
Significa elaborar os similares feitos 
por etapas e anteriormente 


continuar por 
incrementos. 


Figura 2 — Termos relacionados à atividade de projetos 
Fonte: Elaboração própria, 2020 


Pode-se citar como exemplos de projetos: 


* desenvolver um novo produto ou serviço; 

* implementar uma mudança organizacional no que ser refere à estru- 
tura, às pessoas ou ao estilo gerencial; 

* | planejar um novo veículo de transporte; 

* desenvolver ou adquirir um sistema de informação novo ou modificado; 

* construir um prédio ou instalações; 

* levar a cabo uma campanha política; 

* implementar um novo processo ou procedimento organizacional. 


1.1.2 Alguns Conceitos 


Um projeto é um empreendimento único, com início e fim determi- 
nados, que utiliza recursos e é conduzido por pessoas, visando atingir 
objetivos pré-definidos. A Figura 3 é um exemplo de um projeto com as 
características informadas no primeiro conceito. 


Figura 3 — Projeto das ilhas artificiais em Dubai — Palm Jumeirah 
Fonte: https://www.shutterstock.com/pt/image-photo/dubai-palm-jebel-ali-uae-decem- 
ber-353546663 


Para o Pmbok (2014) o projeto é um esforço temporário empreendido 
para criar um produto, serviço ou resultado exclusivo. Ou seja, todo pro- 
jeto tem um início e um fim definidos e deve entregar um resultado sin- 
gular. Acrescenta que, além de ser um empreendimento único que deve 
apresentar um início e um fim claramente definidos, o projeto também 
deve ser conduzido por pessoas para atingir seus objetivos, respeitando 
os parâmetros de escopo, prazo, custo e qualidade (PMBOK, 2015). 


Para a NBR ISO 9000 a atividade de projetos é um conjunto de processos 
que transformam requisitos em características especificadas ou na es- 
pecificação de um produto, processo ou sistema (NBR ISO 9000, 2008). 


Para Healy (1997) os projetos têm objetivos claros e concisos em relação 
a um determinado problema detectado, ou em função de uma oportuni- 
dade ou interesse. De acordo com este autor, o planejamento e execução 
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de um projeto visam a elaboração de uma solução dentro de restrições 
de tempo e recursos. 


Projeto é um empreendimento temporário ou sequência de atividades com 
objetivos claros, definidos em função de algum problema, oportunidade ou, 
até mesmo, interesse de uma pessoa ou organização. Um projeto é um em- 
preendimento com início e fim determinados. Todo projeto tem um ciclo de 
vida próprio. O mesmo é conduzido por pessoas e deve atingir, ao seu final, 
os objetivos dentro do escopo, do prazo, do custo e da qualidade definidas 
(HEALY, 1997, p.9). 


Para a BS 6079-2 (2000) um projeto é um processo único, que consiste 
em um conjunto de atividades coordenadas e controladas com datas de 
início e término, realizadas para atingir objetivos em conformidade com 
requisitos específicos, incluindo restrições de tempo, custo e recursos. 


Diante do apresentado compreende-se que o projeto envolve várias áre- 
as do conhecimento com a finalidade de criar um produto ou serviço, ou 
produzir um resultado específico. 


A execução do projeto é realizada em fases que abrangem o início do 
projeto; organização e preparação; execução do trabalho e encerramen- 
to do projeto. Portanto, existe um ciclo de vida que liga o início ao seu 
final, o que é essencial para que se alcance a excelência em sua realiza- 
ção (VALLE et al., 2010). 


Os projetos atuais são dotados de complexidade técnica e também exi- 
gem grande diversidade de conhecimentos e habilidades. A cada dia sur- 
gem novos desafios para os gerentes de projetos, pois têm que lidar 
constantemente com recursos e prazos limitados em um ambiente de 
incerteza crescente. 


SAIBA MAIS 


Processo - é um conjunto de recursos e atividades inter-relaciona- 
dos que transformam insumos (entradas) em produtos (saídas). 
Essa transformação deve agregar valor na percepção dos clientes 
e exige certo conjunto de recursos. Estes podem incluir pessoal, 
instalações, finanças, equipamentos, métodos e técnicas, numa se- 
quência de etapas ou ações sistemáticas. 


Requisito - é uma necessidade ou expectativa que é expressa, geral- 
mente, de forma implícita ou obrigatória. 


Eu vejo requisitos 
sendo analisados 
erroneamente. 


O tempo 
todo! 


Fonte: Imagens do filme “Sexto Sentido”. 


SAIBA MAIS 


característica especificada ou especificação - apresenta proprieda- 
des diferenciadoras que podem ser: 


e físicas (por exemplo: características mecânicas, elétricas, quími- 
cas ou biológicas); 

* sensoriais (por exemplo: relacionadas com olfato, tato, paladar, 
visão, audição); 

* comportamentais (por exemplo: cortesia, honestidade, 
veracidade); 

* temporais (por exemplo: pontualidade, confiabilidade, dis- 
ponibilidade); 

* -ergonômicas (por exemplo: características fisiológicas relacio- 
nadas à segurança humana); 

* funcionais (por exemplo: velocidade máxima de um avião). 


Resumindo, um projeto é um conjunto de ações que são executadas de 
forma coordenada por uma organização transitória. A esse conjunto de 
ações são alocados os insumos necessários para alcançar um objetivo 
determinado em um prazo estabelecido (VALERIANO, 1998). 
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1.1.3 Temporário 


Temporário significa que cada projeto tem um início e um fim muito bem 
definidos. Chega-se ao fim do projeto quando os seus objetivos foram 
alcançados ou quando se torna claro que os objetivos do projeto não 
serão ou não poderão mais ser atingidos. O projeto é, então, encerrado. 
Temporário não significa que a sua duração seja curta; muitos projetos 
duram vários anos. Em todos os casos, entretanto, a duração do proje- 
to é finita; projetos não são esforços continuados. Além disso, o termo 
temporário geralmente não se aplica ao produto ou serviço criado pelo 
projeto. A maioria dos projetos são empreendidos para criar um resul- 
tado duradouro. Por exemplo, um projeto para erigir um monumento 
nacional criará um resultado que deverá durar séculos. Muitos empre- 
endimentos são temporários apenas no sentido de que eles terminaram 
num momento qualquer. Por exemplo, uma linha de montagem de uma 
fábrica de automóveis poderá eventualmente ser descontinuada, ou a 
própria fábrica ser desativada. Um projeto é fundamentalmente diferen- 
te porque ele termina quando seus objetivos propostos são alcançados, 
enquanto as operações continuadas (não projetos), quando atingem seus 
objetivos, criam um novo grupo de objetivos e o trabalho continua. 


A natureza temporária dos projetos se aplica, também, a outros aspectos 
dos empreendimentos: 


* Aoportunidade ou os nichos de mercado são usualmente temporá- 
rios — a maioria dos projetos têm um espaço de tempo limitado para 
produzir seus produtos e serviços; 


* A equipe do projeto normalmente é desmontada após o projeto — 
os projetos em sua maioria são conduzidos por uma equipe que tem 
o único compromisso com aquele projeto. Ao término do projeto, a 
equipe é liberada e os membros realocados em outras atividades. 


1.1.4 Produto ou Serviço Único 


Os projetos envolvem o desenvolvimento de algo que nunca foi feito an- 
tes e que é, portanto, único. Um produto ou serviço pode ser único, mes- 
mo considerando que já tenha sido desenvolvida uma infinidade de pro- 
dutos/serviços em sua categoria. Por exemplo, muitos e muitos edifícios 
já foram construídos, mas cada nova unidade lançada é única — com um 
proprietário diferente, projeto próprio, localização específica, construtor 
diferente, e assim por diante. A presença de fatores repetitivos não muda 
a característica intrínseca de unicidade do esforço global. Por exemplo: 


* Um projeto para desenvolver um novo tipo de avião comercial pode 
requerer uma série de protótipos; 


* Um projeto para liberação à população de um novo medicamento, 
pode requerer milhares de doses da droga para distribuição em tes- 
tes clínicos; 


* A construção de um conjunto habitacional pode incluir centenas de 
unidades individuais. 


Como o produto de cada projeto é único, as características peculiares 
que o distinguem devem ser progressivamente elaboradas. Progressiva- 
mente significa “proceder por etapas; continuar de forma determinada, 
por incrementos” enquanto elaboradas significa “trabalhadas com cui- 
dado e detalhe; desenvolvidas por completo”. Estas características que 
distinguem os produtos a serem construídos são amplamente definidas 
bem cedo no projeto e se tornam mais explícitas e detalhadas assim que 
a equipe adquire uma melhor e mais completa percepção do produto. 


A elaboração progressiva das características do produto necessita ser cui- 
dadosamente coordenada com a correta definição do escopo do projeto, 
especialmente se o projeto é desenvolvido sob contrato. Quando ade- 
quadamente definido, o escopo do projeto — que define todo o trabalho 
a ser realizado — deve permanecer constante, ainda que as características 
do produto estejam sendo elaboradas progressivamente. 


Os dois exemplos seguintes ilustram o conceito de elaboração progres- 
siva em duas áreas de aplicação diferentes. 


Exemplo 1. Uma fábrica de processamento químico começa com o 
processo de engenharia definindo as características do processo. Estas 
características são usadas para projetar as principais unidades de pro- 
dução. Esta informação, por sua vez, torna-se a base para o design de 
engenharia que define o leiaute detalhado da fábrica e as características 
mecânicas das unidades de processo e das instalações auxiliares. Como 
resultado obtêm-se desenhos de engenharia que são desdobrados para 
produzir desenhos de fabricação (isometria de construção). Durante a 
construção, uma série de interpretações e adaptações são feitas, quando 
necessárias, e submetidas à aprovação formal. Esta “elaboração” poste- 
rior é também transposta para desenhos do que realmente foi construído 
(“as built design”). Durante as fases de teste e manutenção, novas trans- 
formações são frequentemente realizadas sob a forma de ajustes finais. 


Exemplo 2. O produto de uma pesquisa biofarmacêutica pode ser inicial- 
mente definido como “Testes clínicos de XYZ” uma vez que o número e 
o tamanho de cada teste não são conhecidos. Com o início do projeto, 
o produto pode ser descrito mais explicitamente como “Três testes Fase 
|, Quatro testes Fase Il, e Dois testes Fase III”. A próxima etapa na ela- 
boração progressiva pode enfocar exclusivamente os protocolos para os 
experimentos da Fase | — quantos pacientes devem tomar que dosagens 
e com que frequência. Nas fases finais do projeto os testes para a Fase 
III seriam explicitamente definidos, baseados nas informações coletadas 
durante os experimentos das Fases | e II. 
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1.1.5 Caracterizando um projeto público e o ciclo da política pública 


Um projeto público pode ser caracterizado como um conjunto de ações 
que são desenvolvidas por uma organização pública e que tem como 
principal finalidade solucionar algum problema social que se coloca em 
pauta em um contexto municipal, estadual ou federal. Esses problemas 
sociais levam os governos a adotarem esse conjunto de ações que pro- 
curam sanar ou diminuir o seu impacto na sociedade. Esse conjunto de 
ações desenvolvidas conduz a resultados singulares e tem um período 
de tempo definido. Assim, as principais características de um projeto 
estão presentes nas políticas públicas. 


Porém, é importante ter em mente que uma política pública deve ser 
vista com um projeto/programa e que a sua implementação estará su- 
bordinada à visão compartilhada dos vários atores (partes interessadas) 
envolvidos em sua articulação. 


Para Hill e Ham (1997) pode-se definir política pública como um con- 
junto, uma linha ou uma sequência de ações adotadas e perseguidas por 
um governo, partido, legislador, considerado como vantajoso ou opor- 
tuno. Para estes autores a política pública é um processo complexo de 
interações entre os atores estatais e os não estatais e para compreender 
as políticas públicas faz-se necessário compreender o papel do Estado 
na elaboração da mesma, mais ainda, requer uma complexa análise so- 
cial, cultural e institucional. O Estado pode assumir, segundo Hill e Ham 
(1997), duas posições antagônicas. A primeira, um Estado forte que ma- 
nifesta visões poderosas do interesse público, ainda que sujeitas às bar- 
ganhas de interesses específicos e com os gestores fortemente envolvi- 
dos no processo de definição das políticas públicas. A segunda forma é 
um Estado fraco, ou Stateless, que enfatiza a ausência de ideologia para 
determinar um papel especial para o Estado na sociedade e também uma 
visão fragmentada do mesmo. Nos Estados fracos existe uma barganha 
em torno de interesses legítimos que moldam as políticas públicas e os 
gestores são subordinados a cumprir regras neutras e respondem a de- 
mandas levantadas pelos atores que barganham seus vários interesses. 
Com relação às teorias institucionais, Ham e Hill (1993) demonstraram 
em suas argumentações que a visão institucional se faz necessária para 
entender o conceito de políticas públicas, pois existe uma influência in- 
contestável das instituições no processo de formulação dessas políticas. 
Para os autores são as instituições que estabelecem as regras do jogo em 
relação às políticas públicas. Por isso é importante que a visão institucio- 
nalista leve em conta a relação entre estrutura e ação, e não apenas as 
restrições institucionais. Para isso, cabe discutir o papel dos grupos de 
interesse e das comunidades epistêmicas. 


Vale ressaltar, ainda, que a política pública é composta de um processo 
com várias etapas, que alguns autores (LOWI, 1972, RUA, 1998, FREY, 
2000) chamam de ciclo das políticas públicas, representado pela Figura 
4. Ao subdividir o agir público em “fases parciais do processo político- 
“administrativo de resolução de problemas, o policy cycle acaba se reve- 


lando um modelo heurístico bastante interessante para a análise da vida 
de uma política pública” (FREY, 2000, p.226). De forma bem sucinta este 
ciclo é dividido em seis subprocessos, a saber: “percepção e definição 
de problemas, agenda-setting, elaboração de programas e decisão, im- 
plementação da política pública e finalmente, a avaliação de políticas e 
a eventual correção da ação” (FREY, 2000, p.226). Estas várias fases são 
uma sequência de elementos do processo das políticas públicas e podem 
ser investigadas no que diz respeito às constelações de poder, às redes 
políticas e sociais e às práticas político-administrativas que se encontram 
tipicamente em cada fase. 


Identificação do 
Problema 


Ciclo da 
formulação 


da Política 
Pública Formulação de 


Alternativas 


Figura 4 - Ciclo da Política Pública 
Fonte: SECCHI, 2013, p.43 


Percepção e definição de problemas é a etapa em que um problema pas- 
sa a tomar relevância política. Esta relevância pode ser dada por grupos 
sociais isolados, mas também por políticos, grupos de políticos ou pela 
administração pública. A mídia e as outras formas de comunicação políti- 
ca e social têm uma importância grande nesta fase, quando atribuem re- 
levância para o problema peculiar (FREY, 2000). Segundo a visão desen- 
volvida por Easton (1953), é nesta fase que as demandas da sociedade 
são colocadas. Na linguagem desenvolvida pelo autor é nesta fase que os 
inputs (demandas originárias do meio ambiente) e, frequentemente, os 
withinputs (demandas originadas no interior do próprio sistema político) 
são colocadas. 


Na fase da agenda-setting se decide se um tema efetivamente será in- 
serido na pauta política atual ou se o tema deve ser excluído ou adiado 
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para uma data posterior. Para Frey (2000) para se poder tomar a decisão 
de incluir ou não um problema na agenda política, é preciso pelo menos 
uma avaliação preliminar sobre custos e benefícios das várias opções 
disponíveis de ação, assim como uma avaliação das chances de o tema 
ou projeto se impor na arena política. 


Na fase de elaboração de programas e de decisão, faz-se a escolha das 
ações que serão tomadas a partir das várias alternativas existentes. Neste 
momento pode haver conflitos entre os vários atores que influenciam o 
processo político e administrativo. Em geral, a instância de decisão res- 
ponsável decide sobre um programa de compromisso negociado já ante- 
cipadamente entre os atores políticos mais relevantes. Para Frey (2000) 
decisões verdadeiras, isto é, escolhas entre várias alternativas de ação 
são raras exceções nesta fase do ciclo político. 


A fase de implementação de políticas é a fase em que as ações previstas 
na fase anterior são efetivadas junto ao público-alvo das políticas, pro- 
duzindo resultados e impactos. É interessante que nesta fase o interes- 
se das análises políticas está centrado no fato de que, muitas vezes, os 
resultados e impactos reais de certas políticas não correspondem aos 
impactos e resultados projetados na fase de formulação. 


O processo de avaliação é considerado o último passo do ciclo das po- 
líticas públicas. É apontado por alguns autores como uma fase que im- 
pulsiona nova dinâmica e reposiciona as ações que serão tomadas. A 
avaliação é realizada ex-post, porém é desenhada ex-ante e acompanha 
a execução administrativa. Este processo tem forte tradição anglo-saxã e 
tem como objetivos identificar as defasagens, explicá-las e propor medi- 
das para corrigir os déficits de implementação e as lacunas da concep- 
ção/formulação. 


Segundo Frey (2000) é através do processo de avaliação que se apreciam 
os programas já implementados no tocante a seus impactos efetivos. 
Para Frey (2000) com a avaliação da política pública busca-se [...] inda- 
gar os déficits de impacto e os efeitos colaterais indesejados para poder 
deduzir consequências para ações e programas futuros. A avaliação ou 
controle de impacto pode, no caso de os objetivos do programa terem 
sido alcançados, levar ou à suspensão ou ao fim do ciclo político, ou 
caso contrário à iniciação de um novo ciclo, ou seja, a uma nova fase de 
percepção e definição e à elaboração de um novo programa político ou 
à modificação do programa anterior. Com isso, a fase da avaliação é im- 
prescindível para o desenvolvimento e a adaptação contínua das formas 
e instrumentos de ação pública (FREY, 2000, p. 229). 


A avaliação da política pública de um ponto de vista prático visa acompa- 
nhar as políticas e dominar seus efeitos e, de um ponto de vista simbólico, 
procura dar ao cidadão a imagem de uma administração, cuja ação é guia- 
da pela racionalidade e ao mesmo tempo mobilizar os funcionários, inci- 
tando-os a valorizar os resultados de seu trabalho em favor dos usuários. 


Rossi e Freeman (2005) argumentam que os objetivos da avaliação das 
políticas públicas são: 


1. avaliar o valor dos programas em andamento e a necessidade de 
melhorá-los; 

avaliar a utilidade de novos programas e iniciativas; 

aumentar a eficiência do gerenciamento dos projetos; 

satisfazer a necessidade de accountability dos sponsors; 

contribuir para a evolução do conhecimento metodológico das ciên- 
cias sociais. 


ot Ss 


É importante acrescentar, também, que este ciclo não é um modelo de- 
terminístico em que as fases acontecem de forma linear ou racional. Esse 
processo assume um padrão dinâmico de interação e adaptação e acon- 
tece a partir de uma rede de comunicação que se modifica constante- 
mente de forma automática. 


Resumindo, iniciativas baseadas em políticas públicas podem ser geren- 
ciadas como programas e projetos. 


Aqui vale ressaltar que o administrador público deve agir em conformi- 
dade com os preceitos constitucionais relativos à função pública. Esses 
preceitos constitucionais são: 


a) legalidade: como o firme compromisso com o ordenamento jurídico 
e a observância dos atos normativos que o constituem; 


b) impessoalidade: como o dever de agir de modo imparcial perante 
terceiros, sem discriminações, distinções ou preferências; 


c) moralidade: como a obrigação de pautar as ações não apenas pela 
lei, mas também pela boa-fé, lealdade e probidade, evitando desvios 
de finalidade ou abusos de poder; 


d) publicidade e transparência: como a obrigação de tornar públicos e 
abertos dados, informações e ações, disponibilizando-os de maneira 
acessível à população; 


e) eficiência: como a qualidade de quem realiza de maneira diligente as 
suas funções, alcançando a melhor relação entre recursos emprega- 
dos e resultados obtidos. 


Além disso, considero importante enfatizar que, além desses princípios, 
o Administrador Público que irá atuar na condução de projetos públicos 
deve como preceito seguir três regras básicas de comportamento: a) fa- 
zer sempre o que é certo e justo mesmo que isto seja o mais trabalhoso 
e difícil e mesmo quando ninguém esteja olhando; b) tratar os outros 
com empatia, evidenciando o padrão de comportamento com o qual o 
próprio servidor gostaria de ser tratado; e c) reconhecer, por meio de 
suas atitudes, que o orçamento da União, Estados e Municípios e os 
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valores por elas despendidos têm origem no esforço de cada cidadão 
brasileiro e, por isso, deve ser aplicado com a máxima responsabilidade 
e economicidade. 


1.2 O Que é Gerência de Projetos? 


Gerência de Projetos é a aplicação de conhecimentos, habilidades e téc- 
nicas para projetar atividades que visem atingir ou exceder as necessida- 
des e expectativas das partes envolvidas, com relação ao projeto. O ato 
de atingir ou exceder as necessidades e expectativas das partes envolvi- 
das, invariavelmente, envolve o equilíbrio entre demandas concorrentes: 


* escopo, prazo, custo e qualidade; 
* diferentes necessidades e expectativas das partes envolvidas; 
* necessidades concretas e expectativas. 


O termo gerência de projetos é algumas vezes usado para descrever 
uma abordagem organizacional para gerenciamento dos processos ope- 
racionais contínuos. Esta abordagem, mais conhecida como gerência por 
projetos, trata muitos aspectos dos serviços continuados como projetos, 
objetivando aplicar, também a eles, os conceitos de gerência de projetos. 
Embora seja óbvio que o conhecimento de gerência de projetos seja es- 
sencial para uma organização que aplica a gerência por projetos, uma dis- 
cussão detalhada dessa abordagem está fora do escopo deste documento. 


Os processos da gestão de projetos podem ser organizados em cinco 
grupos (Figura 5), cada um deles contendo um ou mais processos: 


1. Processos da Iniciação - reconhecer que um projeto é importante 
para a organização. Nessa fase deve-se começar a pensar nas carac- 
terísticas dos produtos/serviços que deverão ser entregues ao final. 
A decisão aqui é se o projeto deve realmente ser iniciado e a orga- 
nização deverá se comprometer a executá-lo. A fase de iniciação/ 
conceituação é marcada pela definição dos conceitos iniciais básicos 
do projeto, assim como, a identificação dos benefícios em termos 
de dinheiro, produtos ou serviços. O documento que estabelece as 
principais vantagens e parâmetros do projeto é chamado de business 
case e é (ou deveria ser) produzido pelo patrocinador do projeto que, 
na prática, passa a ser o proprietário do documento. Será feita, tam- 
bém, a declaração de requisitos e do escopo do projeto. Nesta fase 
são feitos os testes de viabilidade como viabilidade técnica, comer- 
cial e financeira, estudos técnicos preliminares e as avaliações de in- 
vestimentos. Além disso, será iniciado o processo de gerenciamento 
dos riscos do projeto; 


2. Processos de Planejamento - planejar e manter um esquema de tra- 
balho viável para se atingir aqueles objetivos de negócios que deter- 
minaram a existência do projeto; 


3. Processo de Execução - coordenar o trabalho de pessoas e recursos 
para executar O projeto; 


4. Processo de Controle - assegurar que as metas sejam atingidas atra- 
vés de monitoramento progressivo, tomando ações pró-ativas e rea- 
tivas quando necessário; 


5. Processos de Encerramento - formalizar a aceitação do projeto ou 
fase e encerrá-lo (a) de uma forma organizada. 


Figura 5 — Integração entre as várias fases do processo de gestão de projetos 
Fonte: elaborado pelo autor, 2020 


O conjunto desses cinco processos também é chamado de ciclo de vida 
dos projetos. A duração temporal do ciclo de vida dos projetos pode 
ser de duração curta (poucas semanas) ou de longa duração (meses ou 
anos) e depende de seu conteúdo, complexidade e magnitude. O ciclo 
de vida, usualmente dividido em fases, tem por objetivo melhorar o con- 
trole gerencial. Essas fases compõem uma sequência lógica, criada para 
assegurar uma adequada definição do produto final do projeto. Cada fase 
do projeto é marcada pela conclusão de um ou mais subprodutos, que 
devem ser passíveis de verificação. A conclusão de uma fase é geralmen- 
te marcada pela revisão dos principais subprodutos e pela avaliação do 
desempenho do projeto tendo em vista: a) determinar se o projeto deve 
continuar na sua próxima fase; b) detectar e corrigir erros a um custo 
aceitável. As fases do ciclo de vida do projeto servem para definir o iní- 
cio e o fim de um projeto, assim como determinar os procedimentos de 
transição para o ambiente de operação que serão incluídos ao final do 
projeto. Pode ser usado para ligar o projeto aos processos operacionais 
contínuos da organização. 


São características do ciclo de vida de um projeto: 


a. no seu início, a probabilidade de terminar o projeto com sucesso é 
baixa, aumenta à medida que o projeto caminha em direção ao seu 
término; 


b. a capacidade de as partes envolvidas influenciarem as características 
finais do produto do projeto e seu custo final é alta, no início, e vai se 
reduzindo com o andamento do projeto; 


c. os custos dos recursos do projeto e a quantidade de pessoas aloca- 
das no mesmo são baixos no início, sofrem incrementos no decorrer 
do mesmo e se reduzem drasticamente no final. 
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A figura 6 apresenta uma representação gráfica do ciclo de vida genérico 
de um projeto. 
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As fases se superpõem ao longo de praticamente toda a duração do 
Projeto. 


Figura 6 — Representação gráfica do ciclo de vida de um projeto 
Fonte: elaborado pelo autor, 2020 


Um projeto é uma mudança pontual a ser alcançada utilizando-se de um 
conjunto de tarefas definidas, ordenadas no tempo e inter-relacionadas. 
Essa mudança única é o próprio projeto; o conjunto de tarefas ordenado 
pelo tempo é chamado de sequência do projeto. Então, o gerenciamento 
de projetos nada mais é do que a identificação da mudança única que 
será gerada e a gestão da sequência de tarefas que deverão ser desenvol- 
vidas no projeto. 


1.3 Empreendimentos Relacionados 


Certos tipos de empreendimentos são fortemente relacionados com pro- 
jetos. Estes tipos de empreendimentos estão descritos abaixo. 


Portfólio. Portfólio se refere a uma coleção de projetos, programas, sub- 
portfólios e operações gerenciados como um grupo para o alcance de 
objetivos estratégicos (PMBOK, 2013, p.3). Os portfólios possuem um 
escopo organizacional que muda com os objetivos estratégicos da or- 
ganização. O gerenciamento de portfólios se refere ao gerenciamento 
centralizado de um ou mais portfólios para alcançar objetivos estratégi- 
cos. O gerenciamento de portfólios se concentra em assegurar que os 
projetos e programas sejam analisados a fim de priorizar a alocação de 
recursos e que o gerenciamento do portfólio seja consistente e esteja 
alinhado com as estratégias organizacionais. 


As organizações gerenciam os portfólios com base em seu plano estra- 
tégico. Um objetivo do gerenciamento de portfólios é maximizar o valor 
do portfólio através de um exame cuidadoso de seus componentes: os 
programas e projetos integrantes e outros trabalhos relacionados. Os 
componentes que contribuem menos para os objetivos estratégicos do 
portfólio podem ser excluídos. Desta forma, o plano estratégico de uma 


organização torna-se o fator principal de orientação para investimentos 
em projetos. Ao mesmo tempo, os projetos fornecem feedback aos pro- 
gramas e portfólios através de relatórios de progresso, lições aprendidas 
e solicitações de mudanças que podem identificar os impactos em ou- 
tros projetos, programas ou portfólios. As necessidades dos projetos, 
incluindo as necessidades de recursos, são reunidas e comunicadas de 
volta ao nível do portfólio, o qual, por sua vez, determina a orientação 
para O planejamento organizacional (PMBOK, 2013, p.9). 


Programas. Uma definição de programa é a de uma organização tempo- 
rária criada para coordenar e dirigir trabalhos e supervisionar a entrega 
de uma série de projetos relacionados que contribuem para um deter- 
minado resultado. Um programa é um grupo de projetos gerenciados de 
uma forma coordenada, a fim de se obter benefícios que, de uma forma 
isolada, não se obteria. Muitos programas, também, incluem elementos 
de operações continuadas. Por exemplo: 


* O“Programa avião XYZ” inclui o(s) projeto(s) de design e desenvol- 
vimento da aeronave assim como os serviços continuados de fabri- 
cação e suporte do veículo no campo; 


* Muitas empresas eletrônicas têm “gerentes de programas” que são res- 
ponsáveis tanto pelo desenvolvimento das versões de um produto indi- 
vidual (que são projetos) quanto pela coordenação, ao longo do tempo, 
dessas diversas versões do produto (que são serviços continuados). 


Os programas podem, também, envolver uma série de tarefas repetitivas 
ou cíclicas, como por exemplo: 


* Nos serviços de água, luz e esgoto é comum se falar em “programa 
de construção” anual, significando uma operação continuada regular, 
que envolve muitos projetos; 


* Muitas organizações sem fins lucrativos têm um “programa de cole- 
ta de fundos”. Esse esforço continuado para se obter suporte finan- 
ceiro, frequentemente envolve uma série de projetos discretos, tais 
como campanhas de captação de membros e leilões; 


* A publicação de um jornal ou revista é também um programa — o 
periódico propriamente dito é um esforço continuado, mas a geração 
de cada exemplar individual é um projeto. 


Em algumas áreas de aplicação, a gerência de programas e a gerência de 
projetos são tratados como sinônimos; em outras, a gerência de projetos 
é um subconjunto da gerência de programas. Ocasionalmente, a gerên- 
cia de programas é considerada um subconjunto da gerência de projetos. 
Esta diversidade de significados torna imperativo que, antes de qualquer 
discussão sobre gerência de programas versus gerência de projetos, haja 
uma definição, clara e consistente, entre os participantes, de cada um 
dos termos. 
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Subprojetos. Os projetos são muitas vezes divididos em componentes 
mais gerenciáveis ou subprojetos. Subprojetos são frequentemente con- 
tratados por outra empresa ou outra unidade funcional dentro da mesma 
organização. Exemplos de subprojetos incluem: 


* uma fase de um projeto; 


* uma instalação de acessórios hidráulicos ou elétricos em um projeto 
de construção; 


* testes de programas de computadores em um projeto de desenvolvi- 
mento de software; 


* uma fabricação de alto volume para sustentar ensaios clínicos de 
um novo remédio, durante um projeto farmacêutico de pesquisa e 
desenvolvimento. 


Entretanto, do ponto de vista da organização que desenvolve o projeto, 
o subprojeto é, frequentemente, considerado muito mais um serviço do 
que um produto e este serviço é único. Assim, os subprojetos são tipica- 
mente referenciados como projetos e gerenciados como tal. 


O Quadro 1 sintetiza as principais características de cada um dos concei- 


tos apresentados sobre projeto, programas e portfólios. 


Projeto 


Programas 


Portfólios 


Projetos têm um escopo 
estreito, com produtos 
específicos 


Programas têm um es- 
copo amplo que pode 
mudar para alcançar os 
benefícios | esperados 
pela organização 


Portfólios têm um es- 
copo de negócios que 
muda com as metas es- 
tratégicas da organização 


O gerente de proje- 
tos tenta minimizar as 
mudanças 


Gerentes de programas 
devem esperar as mu- 
danças e até incluí-las 


Gerentes de portfólios 
monitoram | continua- 
mente as mudanças num 
ambiente mais amplo 


O sucesso é medido 
pelo orçamento, pontu- 
alidade e produtos con- 
forme a especificação 


O sucesso é medido em 
termos de Retorno sobre 
o Investimento, novas 
capacidades e benefícios 
alcançados 


O sucesso é medido 
conforme o desempe- 
nho agregado dos com- 
ponentes do portfólio 


Estilo de liderança foca- 
do na entrega da tarefa e 
direcionado no sentido 
de atender aos critérios 
de sucesso 


Estilo de liderança foca- 
do na administração de 
relacionamentos, e reso- 
lução de conflitos. 
Gerentes de progra- 
mas devem facilitar e 
lidar com os aspectos 
políticos da gestão de 
stakeholders 


Estilo de liderança ba- 
seado na agregação de 
valor ao tomador de de- 
cisão do portfólio 


Gerentes de projetos ge- 
renciam técnicos, espe- 
cialistas, etc. 


Gerentes de programas 
gerenciam gerentes de 
projetos 


Gerentes de portfólio 
podem gerenciar ou co- 
ordenar a equipe de ad- 
ministração do portfólio 


Gerentes de projetos 
são membros da equi- 
pe que motivam usando 
seus conhecimentos e 
habilidades 


Gerentes de programas 
são chefes providos de 
visão e liderança 


Gerentes de portfólio 
são providos de discer- 
nimento e síntese 


Gerentes de projetos 
conduzem um planeja- 
mento detalhado para 
atingir a entrega dos 
produtos do projetos 


Gerentes de programas 
criam planos de alto ní- 
vel orientando projetos, 
em que são criados pla- 
nos detalhados 


Gerentes de portfólio 
criam e mantêm pro- 
cessos e comunicação 
necessários para agregar 
ao portfólio 


Gerentes de projetos 
monitoram e controlam 
as tarefas e o trabalho 
de produção dos produ- 


Gerentes de programas 
monitoram projetos e 
trabalhos em andamento 
pela estrutura de gestão 


Gerentes de portfólio 
agregam desempenho e 
avaliam indicadores 


tos do projeto 


Quadro 1 - Síntese das características de projetos, programas e portfólios 
Fonte: Elaboração própria a partir do PMBOK, 2013. 


1.4 Legislações Específicas que Afetam a Gerência de 
Projetos em Organizações Públicas 


A Administração Pública é definida como, conjunto de órgãos, agentes 
e serviços com funções que têm como objetivo final estabelecer a orga- 
nização na administração do Estado, pela definição de normas e regras, 
para atendimento das necessidades coletivas. A Administração Pública é 
dividida em: Administração Pública Direta, Administração Pública Indire- 
ta e Terceiro Setor. A Administração Pública Direta é o conjunto da União, 
Estados, Municípios e Distrito Federal. A União é dotada de soberania, 
ou seja, possui poderes para decidir o seu próprio rumo. Enquanto os Es- 
tados, Municípios e Distrito Federal são dotados de autonomia, que sig- 
nifica a descentralização de alguns poderes de decisão. A Administração 
Pública Indireta é composta pelas Autarquias (possuem certa autonomia 
na administração pública), Fundações (mantidas com orçamento públi- 
co, possuem objetivos específicos e não visam lucro), Empresas Públicas 
(possuem objetivos específicos e visam lucro, explorando algum setor 
comercial) e Sociedades de Economia Mista (semelhantes às empresas 
públicas, mas parte do seu capital investido é privado). O Terceiro Setor 
são as sociedades paraestatais, que não são do Estado, nem considera- 
das Administrações Diretas ou Indiretas, mas atuam paralelamente ao 
Estado, prestando serviços de interesse público. 


Como no processo de gerenciamento de projetos em empresas privadas, 
os projetos que são desenvolvidos na esfera das organizações públicas 
devem estar alinhados com o planejamento estratégico governamental. 
Esse planejamento estratégico governamental nada mais é do que ativi- 
dade fundamentada em ações conscientes no âmbito de garantir deter- 
minado resultado, levando em consideração as informações disponíveis 
e alguns conceitos de atividades no setor público. 


Além do alinhamento com o planejamento estratégico governamental, 
é de fundamental importância que o processo de gestão de projetos em 
organizações públicas leve em consideração algumas legislações especí- 
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ficas, a saber: o Plano Plurianual de Ação Governamental (PPAG), Lei Or- 
çamentária Anual (LOA), Lei de Diretrizes Orçamentárias (LDO), Lei de 
Responsabilidade Fiscal e a Lei de Licitações (Lei nº 8.666 de 21/06/93). 


1.5 Exemplo de um Projeto de Tecnologia 
de Informação 


1.5.1 Objetivo do Projeto - O que se pretende alcançar? 


O objetivo deste projeto é o desenvolvimento de um sistema de registro 
de consultas médicas e atualização de prontuários nas Clínicas de Saúde 
da Família do Sistema Único de Saúde (SUS), utilizando comunicação 
sem fio. No Brasil existem milhares de Clínicas de Saúde da Família, nos 
municípios distribuídos por regiões geográficas. Além disso, temos um 
sistema de informações gerenciais que automatizou todo o processo de 
gestão das clínicas, desde o atendimento inicial até o controle dos pron- 
tuários. O nosso tempo de atualização do prontuário do paciente é de no 
máximo 24 horas, a partir da consulta. 


Com a implementação deste sistema automatizado, pretende-se facilitar 
o processo de controle para emissão de guias de exames e disponibiliza- 
ção de medicamentos necessários para os pacientes que necessitarem. 
Pretende-se diminuir o tempo de entrega de medicamentos para, no má- 
ximo, 3 dias com a implementação desta tecnologia. 


1.5.2 Metodologia de Desenvolvimento do Projeto 


Para o desenvolvimento deste sistema será montada uma equipe mul- 
tidisciplinar composta por sete integrantes. Estes ficarão responsáveis 
pelo delineamento das diretrizes centrais do sistema. Os integrantes se- 
rão os seguintes: 


Um Gestor de Clínicas de Saúde da Família, 

Dois médicos voluntários que atuam em Clínicas de Saúde da Família, 
Um gestor do sistema de informações, 

Um responsável pelo processo de entrega de medicamentos, 

Um gestor de compras, 


Doom o UNS 


Um representante da empresa contratada para desenvolver o projeto. 


Esta equipe irá acompanhar todo o desenvolvimento deste projeto até a 
sua implementação final. 


Serão realizadas reuniões semanais da equipe de desenvolvimento quan- 
do serão acompanhadas todas as etapas de desenvolvimento do projeto. 


Serão estabelecidos mecanismos de controle do projeto e indicadores de 
desempenho para acompanhar o andamento do projeto. 


1.5.3 Etapas do Projeto - Como será desenvolvido o projeto? 


1. 


9, 


Diagnóstico da situação atual das Clínicas de Saúde da Família - Nesta 
etapa do projeto, serão estudadas as atuais necessidades das Clínicas 
de Saúde da Família em relação à atualização do prontuário médico 
dos pacientes. Serão levantados junto aos médicos (as), enfermei- 
ros (as) e farmacêuticos (as) as principais dificuldades encontradas 
e como são os procedimentos de cada um. Estes dois documentos 
gerados servirão de base para a próxima fase do projeto. 


Delineamento do projeto de automatização da atualização do pron- 
tuário médico dos pacientes - Descrever o que será desenvolvido 
nesta etapa e quais são os resultados esperados. 


Definição das tecnologias disponíveis - Descrever o que será desen- 
volvido nesta etapa e quais são os resultados esperados. 


Escolha da tecnologia que será utilizada - Descrever o que será de- 
senvolvido nesta etapa e quais são os resultados esperados. 


Contatos com empresas fornecedoras - Descrever o que será desen- 
volvido nesta etapa e quais são os resultados esperados. 


Levantamento de propostas técnicas e orçamentos - Descrever o que 
será desenvolvido nesta etapa e quais são os resultados esperados. 


Escolha do(s) fornecedor(es) - Descrever o que será desenvolvido 
nesta etapa e quais são os resultados esperados. 


Detalhamento técnico do projeto - Descrever o que será desenvolvi- 
do nesta etapa e quais são os resultados esperados. 


Execução do projeto. 


1.5.4 Cronograma Físico 


Etapas do projeto Período (em meses) 


il 2 3 4 5 6 Fá ô 9 O 


ti 


12 


Diagnóstico inicial 


Delineamento inicial 
do projeto 


Definição das tecno- 
logias existentes 


Escolha da Tecnologia 
que será utilizada 


Contatos com empre- 
sas fornecedoras 


Levantamento de 
propostas técnicas e 
orçamentos 


Escolha dos 
fornecedores 


Detalhamento técnico 
do projeto 


Execução do projeto 
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1.5.5 Quadro de Investimentos 


Item (descrição do item de investimento) Valor (em reais) 


1. Gastos em estudos e em pesquisas preliminares 


2. Construção civil necessária 


3. Gastos com equipamentos 


4. Móveis e utensílios 
Total do investimento 


Imprevistos 


ATIVIDADES 


IE 


Em relação ao conceito de projetos, pode-se afirmar que: 


Um projeto é formado por um esforço, não permanente, para a 
criação de um produto ou serviço. 


Considerando a característica da temporalidade, o projeto é fi- 
nalizado quando seus objetivos são alcançados, quando não for 
mais necessário ou quando ficar bem claro que seus objetivos 
não poderão ser atingidos ou não é compensador ir em frente. 


Considerando a característica da temporalidade, o projeto ne- 
cessariamente tem curta duração. 


Um projeto envolve vários esforços de uma organização, sendo 
executado de maneira ordenada em busca do objetivo proposto. 


O projeto é um empreendimento temporário ou uma sequência 
de atividades com começo, meio e fim programados que têm 
por objetivo fornecer um produto singular, dentro de restrições 
orçamentárias. 


Em relação às afirmações acima, marque a opção correta: 


poe 


Somente as opções | e Il estão corretas. 
Somente as opções |, Il e Ill estão corretas. 
Somente as opções IV e V estão corretas. 
Somente as opções |, II, IV e V estão corretas. 
Todas as opções estão corretas. 


Das atividades abaixo, qual se aproxima mais de uma atividade 
que pode ser considerada de projetos. Justifique a sua escolha, 
considerando os fatores que conceituam um projeto: 


Desenvolvimento de um novo medicamento por uma empresa 
farmacêutica. 


m0oo» 


ion io) (O) fee) 2> 


Montagem de um veículo na linha de produção. 

Assentar tijolos em uma parede da cozinha de uma nova casa. 
Montagem de um computador pela Dell Computer. 
Lançamento de notas fiscais em um sistema contábil de uma 
empresa. 


Qual dos itens a seguir não é um atributo de projeto? 


Data de início definida. 

Não ter data de término definida. 

Criação de um produto, serviço ou resultado exclusivo 
Requerer recursos. 

É conduzido por pessoas 


A gestão de projetos é uma atividade complexa e desafiadora, 
criativa e desgastante; é um processo que tem potencial ilimita- 
do e, mesmo assim, padrões previsíveis. Com relação aos prin- 
cipais fundamentos e características que permeiam o conceito 
de projetos, julgue a alternativa CORRETA: 


Nas empresas, em geral, o projeto se refere a um conjunto de 
atividades relacionadas umas às outras, envolvendo habitual- 
mente um grupo de pessoas que trabalham em conjunto em 
alguma coisa que será realizada várias vezes, durante um longo 
período de tempo não definido. 

O ciclo de vida de um projeto típico abrange apenas 2 fases 
distintas, que são: o planejamento e a implementação. 

Uma vez que cada fase tem seu próprio conjunto de objetivos, 
atividades, ferramentas e qualificações, as principais tarefas e 
atividades dessas fases nunca se superpõem. 

Os projetos são realizados em todos os níveis da organização e 
podem envolver uma única pessoa ou muitos milhares de pes- 
soas. Sua duração varia de poucas semanas a vários anos. 

A equipe de gerenciamento de projetos possui uma responsabi- 
lidade profissional com a organização executora, com o público 
e com suas partes interessadas, excetuando os clientes. 


Dos itens a seguir, qual é a ordem lógica dos processos de ge- 
renciamento de projetos? 


Início, planejamento, monitoração e controle, execução. 
Planejamento, início, monitoração e controle, execução, 
encerramento. 

Início, planejamento, execução, monitoração e controle, 
encerramento. 

Planejamento, início, execução, encerramento. 

Planejamento, início, monitoração e controle, execução e 
encerramento. 
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Respostas comentadas das questões 


Questão 1 - A opção correta é a letra D, pois a afirmação contida na 
terceira afirmação é incorreta devido ao termo “o projeto necessa- 
riamente tem curta duração”. Um projeto pode ser de curta, média 
ou longa duração. 


Questão 2 - A opção correta é a letra “A - Desenvolvimento de um 
novo medicamento por uma empresa farmacêutica”, pois essa ati- 
vidade envolve as características de temporalidade, gerando um 
produto singular. Todas as outras opções caracterizam-se como ati- 
vidades continuadas. 


Questão 3 - À opção correta é a letra “B - Não ter data de término 
definida”. 


Questão 4 - A opção correta é a letra “D - Os projetos são realizados 
em todos os níveis da organização e podem envolver uma única 
pessoa ou muitos milhares de pessoas. Sua duração varia de poucas 
semanas a vários anos”. 


Questão 5 - A opção correta é a letra “C - Início, planejamento, exe- 
cução, monitoração e controle, encerramento”. 
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CAPÍTULO II 


METODOLOGIAS PARA 
GERENCIAMENTO DE PROJETOS 


Prof. Ricardo Thielmann 


Objetivos Específicos 


O objetivo deste capítulo 2 é apresentar ao aluno as principais metodo- 
logias existentes para realizar o gerenciamento de projetos. 


Introdução 


Muitas profissões diferentes têm contribuído para a teoria e a prática do 
gerenciamento de projetos. Engenheiros e arquitetos administram gran- 
des projetos desde a pré-história. A partir da década de 60 do séc. XX, 
tem havido esforços para profissionalizar a prática do gerenciamento de 
projetos como uma especialização própria. Muitas questões têm sido 
colocadas desde então: 


a) Será que o gerenciamento de projetos deve ser uma profissão da 
mesma forma que a engenharia, a contabilidade e a medicina? 


b) Será que é necessário criar associações profissionais que certifiquem 
quem está legalmente autorizado a usar o título de trabalho e quem 
pode exercer a profissão legalmente? 


c) Será que se faz necessário garantir um nível de qualidade mínimo e 
criar regras de comportamento que disciplinem os profissionais que 
atuam na área e que apresentam comportamentos inadequados? 


d) Quanto conhecimento do setor é exigido de um gerente de projeto 
experiente? 


e) Com que facilidade um gerente de projeto de um setor pode fazer a 
transição para outro setor? 


A partir dessas questões, muitos profissionais têm se esforçado para for- 
malizar organizações que criem padrões para a atuação na área de ge- 
renciamento de projeto. Hoje, existem duas grandes organizações com 
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impacto mundial na prática de gerenciamento de projetos: o Project Ma- 
nagement Institute (PMI), com sede mundial nos Estados Unidos e a In- 
ternational Project Management Association (IPMA), com sede mundial 
na Suíça. 


As principais associações, segundo Patah e Carvalho (2012, p. 6) estão 


apresentadas no Quadro 1. 


Associação Padrão/Método Origem 
Project Management | Project Management EUA 
Institute Body of Knowledge 
(PMBOK) 


International Project 
Management Associa- 
tion (IPMA) 


ICB - IPMA Compe- 
tence Baseline 


União Europeia 


Office of Government | Projects In Controlled Reino Unido 
Commerce (OGC) Environments (PRIN- 
CE2) 
Australian Institute of | AIPM - Professional Austrália 
Project Management | Competency Standar- 
(AIPM) ds for Project Mana- 
gement 
Association for Project | APM Body of Know- Reino Unido 
Management (APM) ledge 
Japan Project Mana- ENAA Model Form Japão 
gement Forum (IPMF) | International Con- 


tract for Process Plant 
Construction 


Quadro 1 - Principais Associações e seus Métodos 
Fonte: Adaptado de Patah e Carvalho (2012, p. 6) 


Vale ressaltar que não será possível explorar de forma detalhada todas 
essas abordagens apresentadas no Quadro 1. O foco principal a ser apre- 
sentado neste livro será o Project Management Body of Knowledge. 


2.1 O Project Management Institute (PMI) 


O Project Management Institute (PMI) foi fundado em 1969 por cinco vo- 
luntários, com o objetivo inicial de estabelecer uma organização em que 
os membros pudessem compartilhar suas experiências em gerenciamen- 
to de projetos e discutir questões relacionadas à temática. Atualmente, 
o PMI é uma associação profissional de gerenciamento de projetos sem 
fins lucrativos e é considerada a mais amplamente reconhecida em ter- 
mos de promoção das melhores práticas de gerenciamento de projetos. 
A principal premissa do PMI é que as ferramentas e técnicas de geren- 
ciamento de projetos podem ser compartilhadas pelas mais diferentes 
organizações e a aplicação dessas ferramentas e técnicas têm seu uso e 
aplicação em diferentes tipos de projetos, desde os de desenvolvimento 
de um software até os de construção civil. O PMI começou a oferecer o 


exame de certificação Project Management Professional (PMP) em 1984. 
Embora demorasse um pouco para que as pessoas notassem, agora mais 
de 1 milhão e quatrocentas mil pessoas em todo o mundo possuem a 
certificação do PMP (PMI, 2018). 


Para ajudar a manter os termos e conceitos de gerenciamento de proje- 
tos claros e consistentes, o PMI lançou o livro Um Guia para o Conjunto 
de Conhecimentos em Gerenciamento de Projetos (Guia PMBOKO) em 
1987. Ele foi atualizado em 1996, 2000, 2004, 2009, 2013 e, mais recen- 
temente, em 2017 com a sexta edição. O Guia PMBOKO - Sexta Edição 
está disponível, em versões impressa e digital, em inglês e mais 11 idio- 
mas adicionais (árabe, chinês, francês, alemão, hindi, italiano, japonês, 
coreano, português brasileiro, russo e espanhol). 


Atualmente, há mais de um milhão de cópias do Guia PMBOK em cir- 
culação. O conceituado Instituto de Engenheiros Elétricos e Eletrônicos 
(IEEE) o adotou como seu padrão de gerenciamento de projetos. Em 
1999, o PMI foi credenciado como desenvolvedor de padrões do Ame- 
rican National Standards Institute (ANSI) e também recebeu a distinção 
de ser a primeira organização a ter seu programa de certificação a ob- 
ter o reconhecimento da International Organization for Standardization 
(ISO) 9001. 


Em 2018, a organização relatou mais de 1 milhão e quatrocentos mil 
membros em mais de 203 países. 


O PMI tem sua sede na Pensilvânia, Estados Unidos. 


Devido à importância dos projetos, a disciplina de gerenciamento de 
projetos evoluiu para um corpo funcional de conhecimento conhecido 
como PMBOK - Conjunto de conhecimentos em gerenciamento de pro- 
jetos. O PMI é responsável por desenvolver e promover o PMBOK. O 
PMI também administra um programa de certificação profissional para 
gerentes de projeto, o PMP. Portanto, se você deseja se aprofundar em 
gerenciamento de projetos, o PMBOK é o lugar por onde começar e, se 
você deseja tornar o gerenciamento de projetos sua profissão, considere 
se tornar um PMP. 


2.1.1 O Project Management Body of Knowledge (PMBOK) 


O Project Management Body of Knowledge (PMBOK) destaca que o ge- 
renciamento de projetos é: 


[...] a aplicação de conhecimentos, habilidades, ferramentas e técnicas às 
atividades do projeto a fim de atender aos seus requisitos, [...] realizado por 
meio da aplicação e integração apropriadas de processos de gerenciamento 
de projetos agrupados logicamente (PMBOK, 2013, p.417). 


Nele o processo é dividido em cinco fases distintas que devem ser segui- 
das para a realização de um projeto: iniciação, planejamento, execução, 
monitoramento e controle, e encerramento. Segundo Santos et al (2017): 
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A iniciação trata dos processos de elaboração do termo de abertura do pro- 
jeto e identificação das partes interessadas. O planejamento engloba todos 
os processos que definirão a condução do projeto, desde a definição de cada 
entrega, prazos, tratamento dos riscos, controle dos custos, entre outros. A 
execução corresponde às entregas do projeto, com processos de desenvol- 
vimento da equipe, a realização das aquisições, o gerenciamento da equipe 
e interações com as partes interessadas. O monitoramento e controle são 
todos os processos que controlam as definições do planejamento e as res- 
pectivas entregas. O encerramento trata da conclusão do projeto, encerra-se 
apenas uma fase ou o projeto como um todo por meio do termo de encerra- 
mento (SANTOS, et al., 2017, p.61). 


Então, o Pmbok é um guia, onde se descreve a somatória de conhe- 
cimento e as melhores práticas dentro da área de gerência de proje- 
tos. Todo o conhecimento reunido neste guia é comprovado e não se 
restringe somente a práticas tradicionais, mas também às inovadoras e 
avançadas. Ele é um material genérico que serve para todas as áreas de 
conhecimento, ou seja, tanto para construção de edifício ou processo 
de fabricação industrial como para a produção de software. Um outro 
objetivo do PMBOK é a padronização de termos utilizados em gerência 
de projetos. 


2.2 O PRINCE2 PRojects IN Controlled Environments 


Em 1989, o PRINCE foi lançado pela Central Computer and Telecommu- 
nications Agency (CCTA) e substituiu o PROMPT II nos projetos do Go- 
verno do Reino Unido. O PRINCE teve uma nova versão lançada em 1996, 
passando a se chamar PRINCE2. O PRINCE2 é um modelo mais genérico 
de gestão de projetos, levando o mesmo para diversos segmentos e não 
só para a área de tecnologia. A estrutura do método PRINCE2 é compos- 
ta por quatro elementos integrados: princípios, temas, processos e am- 
biente do projeto. A figura 1 demonstra como está modelado o PRINCE2. 
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Figura 1 — Mapa de Processos do PRINCE2 
Fonte: www.prince2 uk 


Segundo Ribeiro (2011), o padrão PRINCE2 é composto de princípios, 
temas, processos e ambiente do projeto que, tratados de forma integra- 
da, propiciam um ambiente controlado e são assim descritos: 


1) 


princípios: formam a base do PRINCE2, são requisitos orientadores 
e boas práticas que determinam se o projeto está sendo genuina- 
mente gerenciado de acordo com o método; 


tema: descrevem os aspectos de gerenciamento de projetos abor- 
dados em paralelo ao longo do projeto. Sendo divididos nos sete 
segmentos que circuncidavam os processos dentro do PRINCE2, 
conforme figura 2; 


processos: escrevem as etapas do ciclo de vida do projeto, desde o 
início até o fechamento do projeto, sendo um conjunto de atividades 
relacionadas que conduzem o projeto ao seu objetivo de forma or- 
ganizada e controlada. Estas atividades são divididas em etapas pré- 
-projeto, estágio inicial, estágios de entrega subsequente e estágio 
final de entrega (FILHO, 2017). O quadro 2 pode explicar melhor os 
tipos de processos dentro do PRINCEZ2; 


ambiente: trata-se da necessidade de adaptar o PRINCE2 ao contexto 
do projeto. O PRINCE2 é uma estrutura flexível que pode ser facil- 
mente adaptada a qualquer tipo ou tamanho de projeto. Note que 
a adaptação neste ponto está relacionada ao tamanho e segmento, 
onde o projeto será executado, mas não na forma. 


Processos 
Directing a 
project 


Descrição 
Objetivo do Processo: Dire- 
cionar o Projeto (processo de 
responsabilidade do Project 
Board) 
Deveres do Project Board: 
* Assegurar a boa 
comunicação; 
* Apoiar o Gerente do Proje- 
to; Tomar decisões; 
* Comprometer recursos; Ser 
responsável pelo projeto; 
* Dar direção ao projeto; 
* Delegar autoridades; 
e Facilitar a integração das 
diversas funções no projeto 
* Formação do Project Board: 
* Representantes do Negócio, 
* Usuários, 
* Fornecedores. 


Atividades 

e Iniciação (começando o 
projeto com o pé direito) 

* Limites do estágio (compro- 
metimento de mais recur- 
sos após verificar os resulta- 
dos até agora) 


Direção ad hoc (monitoran- 
do o progresso, fornecendo 
conselhos e orientações, rea- 
gindoasituações deexceção) 
* Encerramento do projeto 
(confirmação do resultado 
do projeto e fechamento 
controlado). 

Este processo não cobre as 
atividades do dia a dia do 
Gerente de Projeto. 
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Starting up a 
project 


Este é o primeiro processo no 
PRINCE2. E um processo de 
pré-projeto, projetado para 
garantir que os pré-requisitos 
para iniciar o projeto estejam 
em vigor. 

O processo prevê a existên- 
cia de um objetivo do projeto 
que define em termos de alto 
nível o motivo do projeto e o 
resultado que se busca. 


* Garantir que as informações 
necessárias para a equipe do 
projeto estejam disponíveis; 


* Desenhar e nomear a equi- 
pe de gerenciamento de 
projetos; 


Criar o Plano de Estágio de 
Iniciação. 


Initiating a 


Objetivo do Processo: 


Aprovar se há ou não justi- 


project responder questões para ficativa suficiente para pros- 
autorizar o projeto: seguir com o projeto; 

* Estabelecer uma base de ges- 

* A governança está definida? | tão estável para proceder; 
* Estamos preparados? * Doqumentar é cota ár 
» O que dizer às pessoas? existe viabilidade aceitável 
ó : E: . para o projeto; 
* Quais Os riscost e Garantir uma base firme e 
* Quanto? aceitar para o projeto antes 
* O quê? do início do trabalho; 
* Por quê? * Concordar com o compro- 
* Quem? metimento de recursos para 
e Como? a primeira etapa do projeto; 
* Quando? * Habilitar e incentivar o Co- 
mitê Diretor do Projeto a 
assumir a propriedade do 
projeto; 

* Fornecer a linha de base 
para os processos de toma- 
da de decisão necessários 
durante a vida do projeto; 

* Garantir que o investimento 
de tempo e esforço exigido 
pelo projeto seja feito com 
sabedoria, levando em con- 
sideração os riscos para O 
projeto. 

Managing Objetivo do Processo: geren- | * Garantir ao Comitê Diretor 
a stage ciamento da fronteira entre os | | do Projeto que todas as en- 
boundary estágios do projeto. tregas planejadas no Plano 


de Estágio atual foram con- 
cluídas conforme definido; 

* Fornecer as informações 
necessárias para o Comitê 
Diretor do Projeto avaliar 
a viabilidade contínua do 
projeto; 

* Fornecer ao Comitê Diretor 
do Projeto as informações 
necessárias para aprovar a 
conclusão do estágio atual 
e autorizar o início do pró- 
ximo estágio, juntamente 
com seu nível de tolerância 
delegado; 

* Registrar quaisquer medi- 
ções ou lições que possam 
ajudar nas fases posteriores 
deste projeto e/ou outros 
projetos. 


Controlling a 
project 


Objetivo do processo: des- 
crever as atividades de mo- 
nitoramento e controle do 
Gerente de Projeto envolvido 
em garantir que um estágio 
permaneça em curso e reaja a 
eventos inesperados. O pro- 
cesso constitui o núcleo do 
esforço do Gerente de Projeto 
no projeto, sendo o processo 
que lida com o gerenciamen- 
to do dia a dia do projeto. 


Ao longo de uma etapa, have- 

rá um ciclo que consiste em: 

* Autorizar o trabalho a ser 
feito; 

* Coletar informações de pro- 
gresso de todo o trabalho; 

e Observar as mudanças re- 
vendo as situações; 

* Comunicar as necessidades 
de mudanças; 

* Tomar qualquer ação corre- 
tiva necessária. 

Esse processo cobre essas 

atividades, juntamente com 

o trabalho contínuo de geren- 

ciamento de riscos e controle 

de mudanças. 


Managing 
product 
delivery 


Objetivo do Processo: enten- 
dimento do time do projeto 
e fornecedor da necessidade 
quanto às entregas de acordo 
com o especificado. 

O Gerente do Time reporta ao 
Gerentede Projetoasentregas. 


e Certificar-se de que o 
trabalho em produtos 
alocados à equipe seja 
efetivamente autorizado 
e acordado, aceitando e 
verificando Pacotes de 
Trabalho. 

e Garantir que o trabalho 
esteja em conformidade 
com os requisitos das in- 
terfaces identificadas no 
Pacote de Trabalho. 

e Garantir que o trabalho 
seja feito. 

e Avaliar o progresso do 
trabalho e as previsões 
regularmente. 

e Garantir que os produtos 
concluídos atendam aos 
critérios de qualidade. 

* Obter a aprovação para 
os produtos concluídos. 


Closing a 
project 


Objetivo do processo: encer- 
rar o projeto de forma contro- 
lada e organizada 


* Verificar até que ponto os 
objetivos ou metas estabe- 
lecidas no Documento de 
Iniciação do Projeto (PID) 
foram alcançados; 

* Confirmar a extensão do 
cumprimento do Docu- 
mento de Iniciação do Pro- 
jeto (PID) e a satisfação do 
Cliente com as entregas; 

e Obter a aceitação formal 
das entregas; 

* Garantir até que ponto to- 
dos os produtos esperados 
foram entregues e aceitos 
pelo Cliente; 

* Confirmar se os arranjos de 
manutenção e operação estão 
em vigor (quando apropriado); 

* Fazer recomendações para 
ações subsequentes; 


L 


CAPITULO 2 


L 


CAPITULO 2 


46 


* Capturar as lições resultantes 
do projeto e preencher o Re- 
latório de lições aprendidas; 

* Preparar um Relatório Final 


do Projeto; 

e Notificar a organização 
anfitriã da intenção de dis- 
solver a organização e os 
recursos do projeto. 


Quadro 2 - Estrutura dos processos do PRINCEZ. 
Fonte: Adaptado de PRINCE2 (2020) 


Para um detalhamento melhor sobre o PRINCE2 e suas similaridades 
e diferenças com o Pmbok consultar https://www.prince2.com/uk/ 
downloads £download-category-9 


2.3 SCRUM 


Pressman (2011), conceitua SCRUM como um método ágil de desenvol- 
vimento de software que foi criado no início do ano de 1990, baseado 
nos princípios e valores do manifesto ágil, sendo que os ciclos de desen- 
volvimento são compostos por tarefas, dentro de um padrão de processo 
chamado sprint. Cabe ressaltar que assim como o PRINCE2, o SCRUM 
nasceu na área de desenvolvimento de softwares e tecnologia e poste- 
riormente foi aplicado nos mais diversos setores e empreendimentos. 


SAIBA MAIS 


SCRUM - Um grupo de jogadores faz uma formação em torno da 
bola e seus companheiros de equipe trabalham juntos (às vezes, de 
forma violenta!) para avançar com a bola em direção ao fundo do 
campo. No rugby, essa formação é utilizada após determinado inci- 
dente ou quando a bola sai de campo, ou seja, é utilizada para reini- 
ciar o jogo, reunindo todos os jogadores. O uso dessa terminologia 
pareceu adequado porque no rugby cada time age em conjunto, 
como uma unidade integrada, cada membro desempenha um papel 
específico e todos se ajudam em busca de um benefício comum. 


Figura 2 - Imagem do SCRUM 
Fonte: https://en.wikipedia.org/wiki/Scrum (rugby) /media/File:ST vs Gloucester - 
Match - 23.JPG 


As pessoas envolvidas em um SCRUM possuem papéis específicos, re- 
alizam cerimônias (ou encontros) e geram artefatos (produtos ou docu- 
mentos) ao longo do decorrer do projeto. Segundo Sbrocco e Macedo 
(2012), os papéis, as cerimônias e os artefatos são: 


a) 


Papéis: 
Scrum Master: é o responsável por resolver qualquer empecilho que 
atrase o projeto ou impeça a sua execução; 


Team: é o time de desenvolvimento autogerenciável e multidiscipli- 
nar, geralmente uma equipe pequena, que trabalha em conjunto para 
entregar valor ao cliente; 


Product Owner (P.O.): dono do produto, tem o papel de representar 
o cliente, ou seja, é o responsável por gerenciar e garantir que o pro- 
duto traga valor para o cliente. 


Cerimônias: 

Daily Meeting Scrum: reuniões diárias curtas das quais o time par- 
ticipa com comunicações em pé e responde às seguintes questões: 
“o que eu fiz desde a última reunião?”, “o que vou fazer até a próxi- 
ma?”, “tive ou estou tendo algum impedimento?”; 


Sprint Review: revisão da Sprint, quando o time apresenta o que foi 
desenvolvido para o Product Owner e os convidados (Stakeholders); 


Sprint Planning Meeting: planejamento da Sprint, ou seja, o Pro- 
duct Owner define as prioridades de entrega e o time planeja como 
procederá; 


Sprint Retrospective: a retrospectiva da Sprint, tem o objetivo de 
analisar os pontos positivos e negativos da Sprint e promover um 
processo de melhoria contínua nas próximas sprints. 


Artefatos: 
Product Backlog: um documento que especifica a visão do produto, 
modularizado para ser entregue de forma interativa e incremental; 


Sprint Backlog: é a execução das prioridades definidas pelo Product 
Owner, são geralmente quebradas em atividades (tasks). 


Para o SCRUM o ciclo de um projeto é iniciado com o Product Ow- 
ner, criando o backlog do produto (similar a um termo de abertura no 
Pmboky), verificando os riscos, estimando prazos, custos e definindo 
uma lista de prioridades, conforme o desejo do cliente. Assim, o team 
planejará a execução das sprints (tarefas), as executarão e farão o 
acompanhamento podendo rever as mesmas no decorrer do projeto. 


Sabbagh (2013) enumera os benefícios do SCRUM da seguinte maneira: 


a) 


Entregas frequentes de retorno ao investimento dos clientes; 
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b) Redução dos riscos do projeto; 
c) Maior qualidade no produto gerado devido à melhoria contínua; 


d) Mudanças utilizadas como vantagem competitiva, maior plasticidade 
na forma de executar as atividades de um projeto se comparado aos 
modelos formais; 


e) Visibilidade para todas as partes do progresso do projeto; 
f) Redução do desperdício; 


g) Aumento de produtividade. 


SAIBA MAIS 


Para maiores detalhes sobre a metodologia SCRUM existe um Guia 
do SCRUM. Esse material pode ser acessado no site https://www. 
scrumguides.org/download.html. O download em portugues pode 
ser feito. 


Você poderá também ver o vídeo onde Jeff Sutherland explica como 
o SCRUM foi criado. Para isso, acesse o link e veja o vídeo pelo you- 
tube: https://youtu.be/s4thQcgLCgk. 


Você poderá também ver o vídeo resumo de como utilizar o SCRUM. 
Para isso, acesse o link e veja o vídeo pelo youtube: https://youtu. 
be/0715GwWRK3 1. 


2.4 Project Model Canvas 


Project Model Canvas é uma metodologia de gestão de projetos que 
consiste em agrupar e relacionar as diversas áreas de um projeto de for- 
ma visual. Baseado no Business Model Canvas, o professor e consultor 
brasileiro José Finocchio criou o Project Model Canvas, voltado para o 
gerenciamento de projetos. 


O Project Model Canvas consiste em um conjunto de 13 blocos para 
definir o projeto. Cada bloco do Canvas representa uma área do projeto, 
e esses blocos estão diretamente relacionados aos blocos vizinhos. Fica 
mais fácil encontrar inconsistências no projeto e identificar os impactos 
que as alterações em uma área causam nas áreas relacionadas. A Figura 
3, demonstra esses 13 blocos. 


Figura 3 — Dashboard Project Model Canvas. 
Fonte: Elaboração própria, 2020 


Utilizando o Project Model Canvas, o planejamento do projeto pode 
ocorrer com maior participação dos envolvidos facilitando, assim, o pro- 
cesso de comunicação entre as partes. As ideias são discutidas, de modo 
a não haver censura, e colocadas no quadro. A ferramenta usa também 
uma variação da ferramenta 5w2h a fim de responder a questões básicas 
sobre o projeto, como: O que será feito? Por quem? Quanto irá custar? 


As principais vantagens do uso dessa metodologia são: 


1. facilita a compreensão do projeto: tornando a comunicação mais 
democrática e o processo de construção do projeto mais participati- 
vo podendo motivar a equipe; 


2. facilita a identificação de problemas: como o Project Model Canvas 
explicita de forma visual a relação de dependência entre as diversas 
áreas do projeto, as partes podem identificar problemas e inconsis- 
tências muito mais rapidamente na hora do planejamento, gerando 
um plano de ação e tempo de resposta menor do que se trabalhas- 
sem isoladas; 


3. aumento da objetividade: as ações nesse modelo tendem a ser mais 
objetivas e facilmente remanejadas, se necessário. 
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ATIVIDADES 


1. Na metodologia SCRUM, o que representa uma sprint? 


2. Quais os três principais papéis utilizados pelos praticantes da 
metodologia SCRUM? 


3. A metodologia SCRUM prega a realização de determinadas ceri- 
mônias durante o processo de desenvolvimento. Quais são essas 
cerimônias e os principais artefatos gerados ao final delas? 


4. Qual o papel desempenhado pelo chamado Product Owner? 


D. O SCRUM Master representa o líder da equipe? Comente seu 
papel. 


6. Quais são as responsabilidades da equipe SCRUM? 


7. Qual é o objetivo da reunião de retrospectiva da sprint e quem 
deve participar dela? 


Respostas comentadas das questões 
Respostas retiradas do manual do SCRUM publicado em português 
- Um guia definitivo do SCRUM: as regras do Jogo. 


Questão 1. Na metodologia SCRUM, o que representa uma sprint? 


O sprint é um dos pilares de um projeto de desenvolvimento ba- 
seado na metodologia Scrum e consiste em sua divisão em etapas. 
Cada uma dessas fases possui um tempo definido, que pode ser um 
ciclo com duração de uma semana, duas semanas ou até um mês. 


O sprint pode ser considerado o principal evento do método Scrum, 
porque é nele que serão aplicados os demais eventos, utilizados os 
artefatos produzidos anteriormente e desenvolvido de fato o produ- 
to. É nele que ocorre a produção de um produto ou parte dele. 


A criação de um sprint envolve um trabalho constante de comunica- 
ção entre os times de desenvolvimento, o Scrum Master e o Product 
Owner. Eles devem compartilhar suas necessidades, sua capacidade 
de produção e sua evolução no alcance das metas, a fim de evitar a 
quebra de expectativas ao final de cada etapa. 


A duração da Sprint é time-boxed, isto é, limitada a um tempo, e 
pode variar de uma a quatro semanas, dependendo da produtivida- 


de do time para entregar uma funcionalidade completa (no caso dos 
projetos de TI) ou uma parte funcional do produto (em projetos de 
outras áreas). Porém, uma vez decidida a duração da Sprint, ela deve 
ser mantida até o final do projeto. 


Questão 2: Quais os três principais papéis utilizados pelos pratican- 
tes da metodologia SCRUM? 


O Time Scrum consiste em um Product Owner, o Time de Desen- 
volvimento e um Scrum Master. 


O Product Owner, ou dono do produto, é o responsável por maxi- 
mizar o valor do produto resultado do trabalho do Time de Desen- 
volvimento. Como isso é feito pode variar amplamente através das 
organizações, Times Scrum e indivíduos. 


O Time de Desenvolvimento consiste de profissionais que realizam 
o trabalho de entregar um incremento potencialmente liberável do 
produto “Pronto” ao final de cada Sprint. 


O Scrum Master é responsável por promover e suportar o Scrum como 
definido no Guia Scrum. O Scrum Master faz isso ajudando todos a 
entenderem a teoria, as práticas, as regras e os valores do Scrum. 


O Scrum Master é um servo-líder para o Time Scrum. O Scrum Mas- 
ter ajuda aqueles que estão fora do Time Scrum a entender quais 
as suas interações com o Time Scrum são úteis e quais não são. O 
Scrum Master ajuda todos a mudarem estas interações para maxi- 
mizar o valor criado pelo Time Scrum. 


Questão 3: A metodologia SCRUM prega a realização de determina- 
das cerimônias durante o processo de desenvolvimento. Quais são 
essas cerimônias e os principais artefatos gerados ao final delas? 


Eventos prescritos são usados no Scrum para criar uma regularida- 
de e minimizar a necessidade de reuniões não definidas no Scrum. 
Todos os eventos são eventos time-boxed, de tal modo que todo 
evento tem uma duração máxima. Uma vez que a Sprint começa, 
sua duração é fixada e não pode ser reduzida ou aumentada. Os 
eventos restantes podem terminar sempre que o propósito do even- 
to é alcançado, garantindo que uma quantidade adequada de tempo 
seja gasta não permitindo desperdícios no processo. 


Além da Sprint, que é um container para outros eventos, cada even- 
to no Scrum é uma oportunidade de inspecionar e adaptar alguma 
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coisa. Estes eventos são especificamente projetados para permitir 
uma transparência e inspeção criteriosa. Falhas na inclusão de qual- 
quer um destes eventos resultará na redução da transparência e na 
perda de oportunidades para inspecionar e adaptar. 


Questão 4: Qual o papel desempenhado pelo chamado Product 
Owner? 


O Product Owner, ou dono do produto, é o responsável por maxi- 
mizar o valor do produto resultado do trabalho do Time de Desen- 
volvimento. Como isso é feito pode variar amplamente através das 
organizações, Times Scrum e indivíduos. 


O Product Owner é a única pessoa responsável por gerenciar o Ba- 
cklog do Produto. O gerenciamento do Backlog do Produto inclui: 


* Expressar claramente os itens do Backlog do Produto; 

* Ordenar os itens do Backlog do Produto para alcançar melhor 
as metas e missões; 

* Otimizar o valor do trabalho que o Time de Desenvolvimento 
realiza; 

e Garantir que o Backlog do Produto seja visível, transparente, 
claro para todos, e mostrar o que o Time Scrum vai trabalhar a 
seguir; e, 

e Garantir que o Time de Desenvolvimento entenda os itens do 
Backlog do Produto no nível necessário. 


Questão 5: O SCRUM Master representa o líder da equipe? Comen- 
te seu papel. 


O Scrum Master é responsável por promover e suportar o Scrum 
como definido no Guia Scrum. O Scrum Master faz isso ajudando 
todos a entenderem a teoria, as práticas, as regras e os valores do 
Scrum. 


O Scrum Master é um servo-líder para o Time Scrum. O Scrum Mas- 
ter ajuda aqueles que estão fora do Time Scrum a entender quais 
as suas interações com o Time Scrum são úteis e quais não são. O 
Scrum Master ajuda todos a mudarem estas interações para maxi- 
mizar o valor criado pelo Time Scrum. 


Questão 6: Quais são as responsabilidades da equipe SCRUM? 


Os Times de Desenvolvimento são estruturados e autorizados pela 
organização para organizar e gerenciar seu próprio trabalho. A siner- 


gia resultante aperfeiçoa a eficiência e a eficácia do Time de Desen- 
volvimento como um todo. 


Os Times de Desenvolvimento têm as seguintes características: 


e Eles são auto-organizados. Ninguém (nem mesmo o Scrum 
Master) diz ao Time de Desenvolvimento como transformar o 
Backlog do Produto em incrementos de funcionalidades poten- 
cialmente liberável; 


e Times de Desenvolvimento são multifuncionais, possuindo to- 
das as habilidades necessárias, enquanto equipe, para criar o 
incremento do Produto. 


* | O Scrum não reconhece títulos para os integrantes do Time de 
Desenvolvimento, independentemente do trabalho que está 
sendo realizado pela pessoa; 


* O Scrum não reconhece sub-times no Time de Desenvolvimen- 
to, independente dos domínios de conhecimento que precisam 
ser abordados, tais como teste, arquitetura, operação ou análise 
de negócios; e, 


* | Individualmente os integrantes do Time de Desenvolvimento 
podem ter habilidades especializadas e área de especialização, 
mas a responsabilidade pertence ao Time de Desenvolvimento 
como um todo; 


Questão 7: Qual é o objetivo da reunião de retrospectiva da sprint e 
quem deve participar dela? 


A Retrospectiva da Sprint é uma oportunidade para o Time Scrum 
inspecionar a si próprio e criar um plano para melhorias a serem 
aplicadas na próxima Sprint. 


A Retrospectiva da Sprint ocorre depois da Revisão da Sprint e antes 
do planejamento da próxima Sprint. Esta é uma reunião de no máxi- 
mo três horas para uma Sprint de um mês. Para Sprint menores, este 
evento é usualmente menor. O Scrum Master garante que o evento 
ocorra e que os participantes entendam seu propósito. 
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CAPÍTULO III 


CONDUZINDO UM PROJETO 
SEGUNDO O PROJECT MANAGEMENT 
BODY OF KNOWLEDGE (PMBOK) 


Prof. Ricardo Thielmann 


Objetivos Específicos 


O objetivo deste capítulo 3 é apresentar ao aluno os cinco conjuntos de 
processos definidos pelo PMI para realização da gestão de um projeto. 
Além disso, serão apresentadas formas como os projetos são identifi- 
cados e selecionados. Serão apresentadas ao aluno algumas das princi- 
pais ferramentas utilizadas para realizar o gerenciamento de um projeto, 
como o Termo de Abertura de um projeto, a Estrutura analítica do proje- 
to, a tabela de precedência, o gráfico de Gantt, dentre outras. 


Ao final do capítulo o aluno estará apto a discutir como os projetos 
são identificados e como deverá ser preparado um objetivo claro para 
o projeto. Estará apto a preparar uma tabela de precedência, um gráfi- 
co de Gantt, um cronograma físico e um cronograma financeiro, além 
de outras ferramentas para o planejamento e o controle da execução 
dos projetos. 


Como principal atividade do capítulo 3, o aluno será convidado a 
preparar um planejamento de um projeto que deverá ser escolhido 
pelo aluno. 


Introdução 
A condução de um projeto, segundo o Pmbok (2013), é realizada por 


meio das cinco fases ou dos cinco conjuntos de processos apresentados 
na Figura 5. Esses processos serão detalhados neste capítulo 3. 


A figura 1 apresenta os cinco processos que serão apresentados neste 
capítulo 3. 
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Processo 1 Processo 2 Processo 3 Processo 4 Processo 5 


Iniciação Planejamento Execução Controle Encerramento 


Figura 1- Resumo dos principais processos que serão apresentados no capítulo 3. 
Fonte: Elaboração própria, 2020. 


3.1 Processos de Iniciação de um Projeto 


Os processos de iniciação de um projeto são aqueles executados para 
definir um projeto novo ou uma fase nova de um projeto existente, por 
meio da obtenção de autorização para iniciar o projeto ou fase (PMBOK, 
2013). Nessa fase será definido o escopo inicial do projeto e os recursos 
começarão a ser alocados para que o projeto possa ser iniciado. As par- 
tes interessadas internas e externas ao projeto devem ser identificadas e 
deve-se buscar conhecer quais são os seus interesses e como esses inte- 
resses podem afetar o projeto que será desenvolvido. Será nessa fase de 
iniciação que o gestor do projeto será designado. É importante que essa 
designação seja feita logo no início do projeto para evitar que o gerente 
“pegue o trem andando” (KERZNER, 2017). 


Os principais processos que serão desenvolvidos na fase de iniciação de 
um projeto são os processos para realizar a designação do gerente do 
projeto, realizar a avaliação da viabilidade do projeto, fazer a análise de 
riscos iniciais do projeto, elaborar o termo de abertura do projeto e iden- 
tificar as partes interessadas e seus interesses. A figura 2 ilustra os quatro 
principais processos que devem ser realizados na iniciação do projeto. 


E Z : Elaboração : 

Escolha do Análise da Análise de Gerenciamento das 
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Figura 2 - Processos de iniciação do projeto 
Fonte: Elaboração própria, 2020 


3.1.1 A designação do gerente do projeto 


Como foi dito anteriormente, o ato de escolha e designação do gerente 
do projeto deve ser feito logo no início, para permitir o seu envolvimento 
desde as primeiras etapas de realização do projeto. Diria que essa desig- 
nação deverá ser feita antes mesmo de iniciado o desenvolvimento do 
termo de abertura do projeto. 


Mas a pergunta que fica aqui é: como selecionar um gestor de projetos 
adequado ao projeto? Essa não é uma resposta fácil ou rápida. Mas exis- 
tem alguns indícios que podem permitir que essa escolha seja feita de 


forma profissional e que aumente as chances de sucesso para o projeto. 
Um dos aspectos-chaves para que o projeto tenha sucesso é a escolha 
do gerente do projeto. A literatura que trata do assunto aponta para algu- 
mas características individuais que podem facilitar a escolha do gerente. 


O gerente de projetos trabalha, fundamentalmente, em equipe. Então, 
profissionais que possuem poucas habilidades de relacionamento inter- 
pessoal não são bons candidatos a exercerem este papel. Muitos pro- 
fissionais de projetos chegam ao cargo de gerentes de projetos por se 
destacarem em suas especialidades, mas deveriam ser escolhidos, princi- 
palmente, por se destacarem como bons articuladores e bons gerentes de 
pessoas. Existe, também, o problema cultural em função dos executivos 
não gostarem de serem chamados gerentes de projetos, e outras pessoas 
encararem esta atividade como uma designação altamente temporária 
(CAMARINI e SOUZA, 2006). Portanto, possuir habilidades interpesso- 
ais é a primeira característica a ser buscada em um gerente de projetos. 


Outra constatação importante a ser feita é a diferença fundamental entre 
o gerente de projetos e o gerente funcional ou de linha. O gerente de Ii- 
nha ou funcional tem como objetivo gerenciar a operação em andamento 
com o mínimo de interrupção ou mudança possível. Isso se reflete nas 
características dos dois tipos de gerentes. Enquanto o gerente de projeto 
prospera e é pró-ativo para mudanças, o gerente de linha é reativo para 
mudanças e odeia interrupções. Na prática, isso geralmente cria atrito 
e problemas organizacionais quando uma mudança tem que ser intro- 
duzida. Então, o gerente de um projeto deve se sentir confortável em 
conduzir um conjunto de atividades que têm baixa previsibilidade e alto 
risco de insucesso. Um bom gerente de projeto deve apresentar entu- 
siasmo, força e aptidões para o difícil trabalho de resistência ao ataque 
de interesses técnicos e políticos. Sempre que possível, ele deve possuir 
antiguidade e posição na organização proporcional ao do gerente funcio- 
nal, com o qual terá que negociar. 


O gerente de projetos deve ser um líder. Essa palavra pode estar batida, 
mas o gestor de projetos deve ser capaz de inspirar, persuadir ou influen- 
ciar outros a seguir as ações previstas para o projeto e cumprir um obje- 
tivo definido. Em um contexto político, isso pode ser bom ou mau, mas 
em um ambiente de projeto, geralmente, pode-se presumir que a boa 
liderança é um atributo altamente desejável de um gerente de projeto. 


Para KERZNER (2017) existem dez habilidades que devem ser busca- 
das em um gestor de projetos. Essas dez habilidades estão apresen- 
tadas no Quadro 1. 
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Habilidades Características 
Construção de Equipes | Capacidade de formar e gerenciar equipes de 
trabalho 
Liderança Capacidade de influenciar a equipe e todos os en- 


volvidos no projeto 


Resolução de Conflito | Capacidade de identificar e resolver os conflitos no 
âmbito do projeto 


Competência Técnica | Capacidade de coordenar as ações técnicas do 


projeto 

Planejamento Capacidade de elaborar planos e executá-los 

Organização Capacidade de estabelecer os critérios de trabalho 
no âmbito do projeto 

Empreendedor Capacidade de gerar e gerenciar negócios para o 
projeto 

Administração Capacidade de desenvolver técnicas de controle, 
orçamento, etc. 

Suporte Gerencial Capacidade de gerenciar as interfaces com todos os 
envolvidos no projeto, principalmente com a alta ad- 
ministração 

Alocar Recursos Capacidade de estabelecer os recursos necessários 


as várias fases do projeto 


Quadro 1 - Habilidades do Gerente de Projetos 
Fonte: KERZNER, 2017 


3.1.2 A avaliação de viabilidade do projeto 


Antes de desenvolver um projeto, faz-se necessário mostrar os principais 
benefícios do mesmo em termos de dinheiro, serviços ou ambos. O do- 
cumento que estabelece as principais vantagens e parâmetros do projeto 
é chamado de business case Esse documento procura informar às partes 
interessadas o “porquê” e o “quê” do projeto, bem como apresenta a 
avaliação do investimento que será feito. É altamente desejável ter um 
procedimento claro para desenvolver o business case. Para isso, tenha 


em mente as seguintes questões, segundo (LESTER, 2014, p.21): 


Por que o projeto é necessário? 

O que estamos tentando alcançar? 

Quais são os resultados? 

Qual é o custo previsto? 

Quanto tempo leva para ser concluído? 

Quais padrões de qualidade devem ser alcançados? 
Quais são os critérios de desempenho? 

Quais são os principais indicadores de desempenho (KPI)? 
9. Quais são os principais riscos? 

10. Quais são os critérios de sucesso? 

11. Quais são as principais partes interessadas? 


Do (O (Om O 


A avaliação do investimento, que faz parte do business case, se adequa- 
damente estruturada, melhora o processo de tomada de decisão quanto 
à conveniência ou viabilidade do projeto. A alta administração da organi- 


zação deverá avaliar todas as opções antes de fazer uma recomendação 
firme em relação à autorização ou não do projeto proposto. A avaliação 
do investimento, também, deve incluir uma análise de custo/benefício e 
levar em consideração todos os fatores relevantes, tais como: 


* custos de capital, custos operacionais e custos indiretos; 

* custos de suporte e treinamento; 

* desmontagem e custos de descarte; 

* valor residual esperado (se houver); 

* qualquer economia de custo que o projeto trará; 

* quaisquer benefícios que não podem ser expressos em termos 
monetários. 


Para permitir que algumas das opções sejam comparadas, o payback, 
retorno sobre o capital investido, o valor presente líquido e o lucro espe- 
rado devem ser calculados. Em outras palavras, a viabilidade do projeto 
deve ser estabelecida. 


Não é objetivo deste capítulo detalhar como realizar uma análise de in- 
vestimentos. Esse conteúdo foi tratado nas disciplinas de Finanças, Ad- 
ministração Financeira, Matemática Financeira ou Finanças Públicas, mas 
vale ressaltar a importância de revê-lo para se ter maior confiabilidade 
de que o projeto em questão trará bons resultados para a organização. 


3.1.3 A avaliação de riscos iniciais do projeto 


Em todas as atividades que desenvolvemos no nosso dia a dia, corremos 
risco. Ao atravessar uma rua corremos o risco de sermos atropelados. 
Ao descer de uma escada corremos o risco de perder um degrau e es- 
corregamos no chão. Ao lavar o piso do banheiro podemos escorregar 
na água e no sabão e levamos um tombo. Então, na verdade, a vida seria 
insuportável se nos preocuparmos constantemente se devemos ou não 
realizar uma determinada tarefa, porque o risco é, ou não, aceitável. 


Porém, com projetos não podemos nos dar ao luxo de ignorarmos os 
riscos existentes. Por sua própria natureza, como os projetos são ine- 
rentemente únicos e frequentemente incorporam novas técnicas e pro- 
cedimentos, eles são propensos a riscos, e o risco deve ser considerado 
desde o início. 


Mas o que é um risco? 


Entende-se por risco a possibilidade de ocorrência de um resultado in- 
desejável, como consequência de qualquer evento. O risco é um fator 
inerente ao desenvolvimento de projetos. As consequências dos riscos 
podem afetar o desempenho, pela impossibilidade de atingir determi- 
nado requisito; o custo, por promover despesas acima das orçadas; o 
cronograma, por acarretar atrasos; ou uma combinação destas consequ- 
ências anteriores. 
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Antes de aplicar os procedimentos de gerenciamento de risco, muitas 
organizações elaboram um plano de gerenciamento de risco. Este é um 
documento produzido no início do projeto que estabelece os requisitos 
estratégicos para a avaliação de riscos e todo o procedimento que será 
utilizado para a gestão dos riscos. 


Os riscos têm dois componentes a avaliar: a) a probabilidade de sua 
ocorrência; b) a grandeza ou a severidade do efeito indesejável. 


O gerenciamento dos riscos de um projeto é realizado por meio de seis 
etapas, segundo o Pmbok (2013), que permite que se obtenha uma me- 
lhor compreensão dos riscos do projeto que podem comprometer o cus- 
to, o tempo, a qualidade e a segurança do projeto. São elas: 


a) planejamento do gerenciamento de riscos - consiste em realizar 
um planejamento de como os riscos associados ao projeto serão 
gerenciados; 


b) identificação dos riscos - nessa fase a equipe do projeto começa a 
perceber que existem riscos a serem considerados. Os riscos po- 
dem ser apontados por alguém de fora, ou a equipe pode basear-se 
em sua própria experiência coletiva. O ponto importante é que, uma 
vez que essa atitude mental tenha sido alcançada, ou seja, que o 
projeto, ou certas facetas dele, estão em risco, isso leva muito rapi- 
damente ao processo de identificação dos riscos que nada mais é do 
que a determinação de quais riscos podem ocorrer em um projeto 
em particular; determinar quais deles podem afetar esse projeto e 
documentar suas características. Trata-se de um processo iterativo, 
porque novos riscos podem surgir durante o ciclo de vida do projeto. 
A frequência das interações e de quem deve participar de cada ciclo 
varia de caso a caso. A equipe do projeto deve estar envolvida de 
forma a desenvolver um senso de responsabilidade pelos riscos e 
tomar as ações necessárias. As técnicas mais utilizadas para realizar 
a identificação dos riscos são: análise SWOT, busca de opinião de es- 
pecialistas, revisão de listas de verificações de riscos, brainstorming 
e técnica delphi. O número de técnicas e quando serão utilizadas são 
definidas no plano de gerenciamento de riscos; 


c) análise qualitativa dos riscos - realizar a análise qualitativa dos ris- 
cos é o processo de priorização de riscos para análise ou ação adicio- 
nal através da avaliação e combinação de sua probabilidade de ocor- 
rência e impacto. O principal benefício deste processo é habilitar os 
gerentes de projetos a reduzir o nível de incerteza e focar os riscos 
de alta prioridade. Para identificar a probabilidade de um risco usa-se 


a experiência, dados estatísticos ou a opinião de especialistas. Cada 
risco pode, então, receber uma classificação de probabilidade (ALTA, 
MÉDIA ou BAIXA). De forma semelhante, levando em consideração 
todos os dados estatísticos disponíveis, históricos de projetos ante- 
riores e opinião de especialistas, o impacto ou efeito no projeto pode 
ser classificado como SEVERO, MÉDIO, BAIXO OU NULO. Para 
auxiliar as equipes de projetos a fazerem essa avaliação qualitativa 
existem matrizes padronizadas com percentuais de probabilidade 
e impacto que facilitam a classificação qualitativa dos riscos. Essa 
matriz especifica as combinações de probabilidade e impacto que 
resultam em uma classificação dos riscos como de prioridade baixa, 
moderada ou alta. Podem ser usados termos descritivos ou valores 
numéricos, dependendo da preferência organizacional. Aqueles que 
apresentarem maior probabilidade e impactos serão priorizados para 
a realização de uma análise quantitativa; 


análise quantitativa dos riscos - a análise quantitativa é o proces- 
so de analisar numericamente o efeito dos riscos identificados nos 
objetivos gerais do projeto. O principal benefício desse processo é 
a produção de informações quantitativas dos riscos para respaldar 
a tomada de decisões, a fim de reduzir o grau de incerteza dos pro- 
jetos. A análise quantitativa dos riscos é executada nos riscos que 
foram priorizados pelo processo de realização da análise qualitativa 
dos riscos, como tendo impacto potencial e substancial nas deman- 
das concorrentes do projeto. Apresenta uma abordagem quantitati- 
va para a tomada de decisões na presença da incerteza, utilizando 
técnicas, tais como a análise da árvore de decisão e a simulação de 
Monte Carlo; 


SAIBA MAIS 


Para saber mais sobre a análise da árvore de decisão e a sua aplica- 
ção no gerenciamento de riscos de projetos você poderá consultar 
os seguintes artigos que estudaram essa temática: 


1) 


2) 


DEY, Prasanta K.. MUKHERJEE, S.K.. Project risk management 
in analytic ffamework. International Journal of Industrial Engine- 
ering, 12 (4), p.419-433, 2005. 


DEY, Prasanta K.. Project risk management using multiple crite- 
ria decision-making technique and decision tree analysis: a case 
study of Indian oil refinery. Production Planning & Control, 23 
(12), p.903-921, 2012. 
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Para saber mais sobre a análise de Monte Carlo e a sua aplicação 
no gerenciamento de riscos de projetos você poderá consultar os 
seguintes artigos que estudaram essa temática: 


1) 


OLIVEIRA JUNIOR, Paulo Alves de. DANTAS, Maria José Perei- 
ra. MACHADO, Ricardo Luiz. Aplicação da simulação de Monte 
Carlo no gerenciamento de riscos em projetos com o Crystal 
Ball. IN: Anais do SIMPOI - Simpósio de Administração da Pro- 
dução, Operações e Logística Internacional, USP Brasil, 2013. 


BARAKAT, Majida Farid. BERSSANETI, Fernando Tobal Berssaneti. 
Aplicabilidade do Método de Simulação de Monte Carlos na pre- 
visão de prazo em um projeto de transferência de tecnologia intra 
companhia farmacêutica. IN: XXXVI ENCONTRO NACIONAL DE 
ENGENHARIA DE PRODUÇÃO, João Pessoa/PB, Brasil, 2016. 


JORNADA, Daniel Homrich da Jornada. PIZZOLATO, Morgana. 
Uso de planilhas eletrônicas para implementação do método 
de Monte Carlo para estimativa de incerteza de medição. IN: 
ENQUALAB-2005 - Encontro para a Qualidade de Laboratórios. 
São Paulo, Brasil, 2005. 


SANTOS MACHADO, Nilton Roberto dos. FERREIRA, Alessan- 
dre Oliveira. Método de Simulação de Monte Carlo em planilha 
excel: desenvolvimento de uma ferramenta versátil para análise 
quantitativa de riscos em gestão de projetos. Revista de Ciên- 
cias Gerenciais, v.16, n.23, 2012. 


HILLSON, David. Extending the risk process to manage oppor- 
tunities. International Journal of Project Management, v.20(3), 
2002, pp.235-240. 


AMORIM, Fernando Rodrigues. DE ABREU, Pedro Henrique 
Camargo. PATINO, Marco Tulio Ospina. TERRA, Leonardo Au- 
gusto Amaral. Análise dos riscos em projetos: uma aplicação do 
método de Monte Carlo em uma empresa do setor moveleiro. 
Future Studies Research Journal: Trends and Strategy, v.10(2), 
2018, pp.332-357. 


e) planejar as respostas aos riscos - após listar e avaliar os riscos e 
estabelecer uma tabela de prioridades, a próxima etapa será decidir 
como gerenciar os riscos, ou seja, o que fazer com eles e quem deve 
ser responsável por gerenciá-los. Para todos os efeitos, é aconselhá- 
vel nomear um responsável por gerenciar os riscos identificados e 
controlados. A pessoa designada pode ficar responsável por um gru- 
po pequeno de riscos ou mesmo por todos os riscos identificados. 
Nesse caso, esse responsável é designado como gestor de riscos do 


projeto. Existem várias ações que podem ser tomadas pelos gestores 
de riscos do projeto. Dentre elas podem ser citadas: 


* evitar o risco - trabalhar na prevenção de riscos mais graves, 

* compartilhar o risco, 

* transferir o risco - trabalhar para transferir riscos para terceiros, 

* mitigar o risco - reduzir a probabilidade e as consequências de 
um evento adverso de risco, 

* contingenciar o risco, 

* aceitar O risco - trabalhar com os riscos cuja probabilidade de 
causar algum dano maior ao projeto seja aceitável; 


f) monitorar os riscos - aqui o gestor de riscos do projeto deverá fazer 
o acompanhamento dos riscos em períodos pré-estabelecidos, para 
verificar se eles estão ocorrendo ou não. Claramente, à medida que 
o projeto avança, os riscos reduzem em número, de modo que os 
valores financeiros que foram orçados para cobrir o risco das ativida- 
des concluídas podem ser alocadas a outras seções do orçamento, se 
assim acontecer. 


Existem algumas ferramentas informatizadas que auxiliam no processo 
de gerenciamento dos riscos de um projeto. Os mais conhecidos são o 
(DRISK, Cristal Ball, entre outros. 


3.1.4 Elaboração do termo de abertura do projeto 


O termo de abertura do projeto é o documento que autoriza formal- 
mente o início das atividades de um projeto, após a sua seleção. Nesse 
documento o patrocinador concede a aprovação para a continuidade do 
projeto e confirma o seu financiamento. Além disso, o termo de abertura 
do projeto sintetiza as condições e parâmetros-chaves para o projeto e 
estabelece a estrutura para o desenvolvimento de plano base para a sua 
realização (CLEMENTS e GUIDO, 2013). 


O termo de abertura deverá conter também as premissas e restrições 
existentes no projeto em questão. 


SAIBA MAIS 


Premissas 

Um fator do processo de planejamento considerado verdadeiro, real 
ou certo, desprovido de prova ou demonstração. Também descreve 
o impacto potencial desses fatores se forem comprovados como 
falsos. As equipes de projetos frequentemente identificam, docu- 
mentam e validam as premissas como parte do seu processo de pla- 
nejamento. Informações sobre as premissas podem ser listadas na 
declaração do escopo do projeto ou em um registro separado. Pre- 
missas são todas as limitações de planejamento e execução do proje- 
to que são de exclusiva imposição ou opção do Gerente de Projetos. 
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Exemplos de premissas: 

* Em projetos de desenvolvimento de software (caso o gerente 
tenha a opção), escolher determinada linguagem de programa- 
ção, mesmo sabendo que não é padrão de mercado; 


* Em projetos de engenharia civil, determinar um tipo específico 
de revestimento; 


* Ao planejar uma festa de confraternização, optar por uma área 
ao ar livre mesmo sabendo que, para o mês do evento, as chan- 
ces de chuva são grandes; 


* Aoplanejara próximaviagem definal de ano dafamília, definirare- 
gião Nordeste como alvo, jáque aesposa não definiu preferências. 


Restrições 

Um fator limitador que afeta a execução de um projeto ou processo. 
As restrições identificadas com a declaração do escopo do projeto 
listam e descrevem as restrições ou limitações internas e externas 
específicas associadas com o escopo do projeto que afetam a execu- 
ção como, por exemplo, um orçamento pré-definido ou quaisquer 
datas impostas ou marcos do cronograma comunicados pelo cliente 
ou pela organização executora. Quando um projeto é feito sob con- 
trato, as cláusulas contratuais geralmente são restrições. Informa- 
ções sobre as restrições podem ser listadas na declaração do escopo 
do projeto ou em um registro separado. 


Exemplos de restrições: 
* Orçamento previamente definido, você não poderá ultrapassar 
aquele orçamento; 


* Ninguém da equipe poderá fazer horas extras; 


* Datas impostas (deadlines) para conclusão de alguma entrega ou 
fase do projeto, você não poderá ultrapassar de forma alguma; 


* Quando seu projeto é feito baseado em um contrato, algumas 
cláusulas contratuais são restrições, pois limitam o desempe- 
nho do projeto e devem ser cumpridas; 


e* Membros da equipe que só podem trabalhar em determinado 
período (Ex.: somente no fim de semana). 


Ativos e Políticas Organizacionais 

Segundo o PMI (2015) as políticas organizacionais são inevitáveis nos 
ambientes de projetos devido à diversidade de normas, culturas e expec- 
tativas das pessoas envolvidas em um projeto. O uso hábil de política e 
poder ajuda o gerente de projetos a ter êxito. Contrariamente, ignorar ou 


evitar políticas de projetos e o uso inadequado do poder podem conduzir 
a dificuldades no gerenciamento de projetos. 


Informações preliminares (prazos, custos, riscos e escopo) 

As informações preliminares relativas ao escopo, prazos, custos e riscos 
são levantadas pelo Gerente do Projeto, juntamente com os clientes e 
com as principais partes interessadas. Essas informações preliminares 
poderão ser alteradas na fase de planejamento do projeto. 


Especificação do trabalho / Statement of Work (SOW) 
A especificação do trabalho é uma descrição narrativa dos produtos, ser- 
viços ou resultados a serem fornecidos pelo projeto. 


Acordos ou Contratos 

Os acordos são usados para definir as intenções iniciais de um proje- 
to. Os acordos podem tomar a forma de contratos, memorandos de 
entendimento, acordos de nível de serviço, carta de acordos, cartas de 
intenção, acordos verbais, e-mails, ou outros tipos de acordos por es- 
crito. Normalmente um contrato é usado quando o projeto está sendo 
realizado para um cliente externo. 


SAIBA MAIS 


Memorando de Entendimento 

é um acordo firmado entre duas ou mais partes para alinhar os ter- 
mos e detalhes de um entendimento, assim como seus direitos e 
deveres. 


Na maior parte das vezes, o memorando de entendimento, também 
chamado de MOU (Memorandum of Understanding) serve como 
primeiro passo para a formalização de um documento jurídico mais 
elaborado como um contrato. 


Pode-se considerar o MOU como uma versão mais formal de um 
acordo verbal ou um acordo de cavalheiros. 


Fatores Ambientais 

As condições que não estão sob o controle imediato da equipe e que 
influenciam, restringem ou direcionam o projeto, programa, ou portfólio. 
Os fatores ambientais da empresa são considerados como entradas na 
maioria dos processos, podem aumentar ou restringir as opções de ge- 
renciamento de projetos e podem ter uma influência positiva ou negativa 
nos resultados. O importante para o gerente de projeto é reconhecer 
quais são esses fatores e como eles impactam no projeto durante as 
várias fases, desde o início até a entrega final do projeto. Todas essas 
influências são perfeitamente analisadas, utilizando-se a ferramenta de 
análise PESTLE (do Inglês), que significa: políticos, econômicos, sociais, 
técnicos, legais e de meio ambiente (em inglês Political, Economic, Social, 
Technical, Legal, Environmental). 
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Seleção do gerente do projeto 
No termo de abertura deve ser informado quem será o gerente de proje- 
tos que foi selecionado para conduzi-lo. 


Viabilidade do projeto 

Um resumo da viabilidade do projeto deverá ser um dos itens compo- 
nentes do Termo de Abertura do Projeto. Lembre-se que essa análise já 
foi feita anteriormente e serviu de base para que o projeto em questão 
fosse selecionado. 


Partes interessadas 
Deve-se apresentar um resumo das principais partes interessadas no 
projeto com as informações sobre qual será o interesse e se ele é positi- 


vo ou negativo. 


3.1.5 O gerenciamento das partes interessadas (stakeholders) 
e seus interesses 


SAIBA MAIS 


A MAMÃE CAMELO E SEU BEBÊ 


Mãe, mas 
por quê??? 


Figura 3 - a mamãe camelo e seu bebê. 
Fonte: http://walkiriapensamentos.blogspot.com/2014/01/a-fabula-do- 
-camelo.html 


Uma mãe e um bebê camelo estavam por ali, à toa, quando de re- 
pente o bebê camelo perguntou: 


Bebê: Mãe, mãe, posso te perguntar umas coisas? 

Mãe: Claro! O que está incomodando o meu filhote? 

Bebê: Por que os camelos têm corcova? 

Mãe: Bem, meu filhinho, nós somos animais do deserto, precisa- 
mos das corcovas para reservar água e por isso mesmo somos co- 


nhecidos por sobreviver sem água. 


Bebê: Certo, e por que nossas pernas são longas e nossas patas 
arredondadas? 


Mãe: Filho, certamente elas são assim para permitir caminhar no 
deserto. Sabe, com essas pernas eu posso me movimentar pelo de- 
serto melhor do que qualquer um! — disse a mãe, toda orgulhosa. 


Bebê: Certo! Então, por que nossos cílios são tão longos? De vez em 
quando eles atrapalham minha visão. 


Mãe: Meu filho! Esses cílios longos e grossos são como uma capa 
protetora para os olhos. Eles ajudam na proteção dos seus olhos 
quando atingidos pela areia e pelo vento do deserto! — disse a mãe 
com orgulho nos olhos. 


Bebê: Tá. Então a corcova é para armazenar água enquanto cru- 
zamos o deserto, as pernas para caminhar através do deserto e os 
cílios são para proteger meus olhos do deserto. Então que diabos 
estamos fazendo aqui no Zoológico?? 


Moral da história: 
“Habilidade, conhecimento, capacidade e experiências são úteis se 
você estiver no lugar certo”. 


Existem muitas pessoas ou organizações que têm interesse em um proje- 
to. O tipo e o interesse de uma parte envolvida são de grande importân- 
cia para um gerente de projeto, uma vez que eles o capacitam a usá-los 
para o maior benefício. As partes interessadas ou stakeholders são os in- 
divíduos ou organizações que estarão em algum momento envolvidos no 
projeto, e cujos interesses são afetados pelo desenvolvimento do projeto. 


O processo de listar, classificar (interesses positivos e/ou negativos) e 
avaliar a influência dessas partes interessadas é denominado análise de 
partes interessadas. As partes interessadas podem ser divididas em dois 
grupos principais: a) partes interessadas diretas (ou primárias) e b) as 
partes interessadas indiretas (ou secundárias). 


As partes interessadas diretas são aquelas que estão diretamente asso- 
ciadas ou envolvidas no planejamento, administração ou execução do 
projeto. Isso inclui o cliente, patrocinador do projeto, gerente de proje- 
to, membros da equipe de projeto, prestadores de serviços técnicos e 
financeiros, consultores internos ou externos, fornecedores de materiais 
e equipamentos, pessoal do local, empreiteiros e subcontratados, bem 
como usuários finais. Em outras palavras, pessoas ou organizações di- 
retamente envolvidas em todas ou algumas das várias fases do projeto. 


As partes interessadas indiretas são aqueles que estão indiretamente as- 
sociados ao projeto, como gerentes internos da organização e equipe 
de suporte, que não esteja envolvida diretamente no projeto, incluindo 
o departamento de RH, departamento de contabilidade, secretários(as), 
níveis de gestão sênior que também não estejam diretamente responsá- 
veis pelo projeto e, por último, as famílias do gerente de projeto e dos 
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membros da equipe. Podem ser consideradas, também, partes interes- 
sadas indiretas as autoridades reguladoras, como os governos nacionais, 
estaduais ou municipais, organizações de licenciamento e fiscalização, 
instituições técnicas, órgãos profissionais e grupos de interesse pessoal, 
como acionistas, sindicatos e grupos de pressão. 


Esses grupos geralmente têm interesses positivos, quando apoiam as 
metas e objetivos do projeto, e interesses negativos, quando não apoiam 
o projeto e não desejam que ele prossiga. Geralmente, as partes dire- 
tas interessadas apresentam um comportamento de interesses positivos, 
pois são elas que se preocupam com a concepção e implementação do 
projeto e com a conclusão dos objetivos definidos dentro dos parâme- 
tros especificados de escopo, tempo, custo e qualidade/desempenho. 
Portanto, eles incluem o patrocinador, o gerente de projeto e as equipes 
de design e construção/instalação do projeto. Porém, pode conter partes 
interessadas que têm interesses negativos. Um bom exemplo acontece 
quando funcionários da organização que recebem o resultado final do 
projeto, preferem manter a instalação existente, porque a nova instalação 
pode resultar em realocação ou até mesmo demissão de funcionários. 


O importante nessa fase do processo de iniciação é listar quais são as 
partes interessadas diretas e/ou indiretas e avaliar quais são os seus inte- 
resses positivos e/ou negativos. 


Para isso pode-se utilizar uma matriz que associe a relação das partes in- 
teressadas e seus principais interesses, conforme o modelo apresentado 
na figura 4. 


Parte|Descri- |Nível del|Tipo de|Estratégia|Custo | Respon- 
Interes- | ção da]|Interesse | expecta- | para ganhar | da ação | sável 


sada Parte]|no projeto | tiva e in- | suporte ou 
Interes- | (Alto, Mé- | teresse reduzir obs- 
sada dio, Baixo) táculos 


Figura 4 - Matriz de Gerenciamento das partes interessadas. 
Fonte: Elaboração própria, 2020 


Para o Pmbok (2013) o processo de gerenciamento das partes interessa- 
das acontece por meio dos seguintes processos: 


identificar as partes interessadas; 

planejar o gerenciamento das partes interessadas; 
gerenciar o engajamento das partes interessadas; 

controlar o engajamento das partes interessadas. 


oNcs» 


3.2 Processos de Planejamento de um Projeto 


O processo de planejamento envolve um conjunto maior de processos 
que se inicia com a confirmação e o detalhamento do escopo do projeto 
e termina com a união de todos os documentos produzidos no Plano 
do Projeto. Os processos de planejamento são fundamentais para um 
projeto, para garantir o sucesso de uma atividade que nunca tenha sido 
realizada, com as mesmas características e em uma situação idêntica. 
Como consequência, existem mais processos nessa fase do projeto. Vale 
lembrar que planejar deve ser um esforço contínuo durante toda a vida 
do projeto. O processo de planejar um projeto não mais é do que elabo- 
rar um esquema, ou uma estratégia, que demonstre como as tarefas do 
projeto serão executadas dentro do escopo, do orçamento, do prazo e 
no nível de qualidade esperados. Tentar realizar um projeto sem um pla- 
no é como tentar montar uma bicicleta sem primeiramente ler as instru- 
ções. Pessoas que pensam que o planejamento é desnecessário ou perda 
de tempo, mais tarde, invariavelmente precisam encontrar um tempo 
para refazer as coisas. É importante planejar o trabalho e depois realizar 
o plano. Caso contrário, o resultado será caos e frustração, e o risco de o 


projeto fracassar será maior. 


Os processos de planejamento que serão apresentados a partir de agora 


estão apresentados na figura 5 


Figura 5 - Processos para elaboração do Planejamento do Projeto - processos diretamente 
associados ao escopo do projeto 
Fonte: elaboração própria a partir do Pmbok, 2013 


3.2.1 Planejamento e detalhamento do escopo do projeto 


Nessa etapa/fase do planejamento do projeto será elaborada, por escrito, 
a declaração do escopo como fundamento para futuras decisões do pro- 
jeto. O documento básico que será considerado como entrada para esse 
processo é o Termo de Abertura do Projeto, que contém em seu conte- 
údo o escopo preliminar definido. Aqui o gestor do projeto, juntamente 
com o grupo de pessoas envolvidas no planejamento, devem definir o 
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escopo do produto? e o escopo do projeto”. Nessa etapa/fase será feito o 
desenvolvimento de uma descrição detalhada do projeto e do produto. 
O principal benefício desse processo é que ele descreve os limites do 
projeto, serviços ou resultados ao definir quais dos requisitos coletados 
serão incluídos e quais serão excluídos do escopo do projeto. 


A preparação detalhada da especificação do escopo é crítica para o su- 
cesso do projeto e baseia-se nas entregas principais, premissas e restri- 
ções que são documentadas durante a iniciação do projeto. Durante o 
planejamento do projeto, o seu escopo é definido e descrito com maior 
especificidade conforme as informações a respeito do projeto são conhe- 
cidas. Os riscos existentes, premissas e restrições são analisados para 
verificar sua integridade e acrescentados ou atualizados conforme neces- 
sário (PMBOK, 2013). É importante lembrar que, se o Termo de Abertura 
do projeto foi elaborado com todas as suas partes componentes comple- 
tas, nessa fase será feita apenas a confirmação dos dados existentes nes- 
se documento, pois todas as informações necessárias já estão contidas 
no Termo de Abertura. Porém, se foram feitas alterações nos requisitos 
do projeto, as informações deverão ser atualizadas agora. 


SAIBA MAIS 


Exemplo de uma declaração do escopo de um projeto de implanta- 
ção de um sistema de gestão da qualidade baseado na NBR ISO 9001 


1 - Descrição do Escopo do Projeto 


O projeto de implantação de um sistema de gestão da qualidade ba- 
seado na NBR ISO 9001 será realizado de janeiro de 2020 a dezem- 
bro de 2021, com a alocação de um gerente de projetos, um profis- 
sional da área de engenharia da empresa, um profissional da área de 
qualidade da empresa, um gerente de Marketing, um profissional da 
área de desenvolvimento de novos produtos, de um profissional da 
área de Gestão de Pessoas, três profissionais da área de produção 
e dois profissionais da empresa de consultoria que será contratada 
para auxiliar na implantação do sistema. Será necessário: 


4 O escopo do produto são as características e funções que caracterizam um produto, serviço ou 
resultado. Portanto, abrange todos os requisitos que os stakeholders (partes interessadas) desejam 
que o produto tenha. 


5 O escopo do projeto é todo o trabalho que deve ser realizado para entregar um produto, serviço 
ou resultado com as características e funções especificadas. O termo escopo do projeto às vezes 

é visto como incluindo o escopo do produto. Ele reúne informações relevantes sobre o projeto, 
como: objetivos específicos, entregas, tarefas, responsabilidades, prazos e custos. Além disso, es- 
tabelece os limites do projeto e os critérios de validação e aceitação das entregas. Então, enquanto 
o escopo do projeto diz “COMO” o trabalho deve ser feito, o escopo do produto diz “O QUE” 
deve ser feito. 


* | 200 horas de consultorias para implantação de um sistema de 
gestão baseado na NBR ISO 9001; 


* Oferecer 100 horas de treinamentos para capacitação da força 
de trabalho na interpretação dos requisitos da NBR ISO 9001 e 
100 horas de treinamentos para capacitação e criação do grupo 
de auditores internos da qualidade; 


e Elaborar o manual da qualidade, contendo a descrição de todos os 
processos que serão certificados, assim como: a definição da políti- 
ca da qualidade da empresa, a definição dos objetivos da qualidade, 
a interpretação e descrição dos requisitos do sistema de gestão da 
qualidade aplicado para a empresa, a definição dos procedimentos 
operacionais padrões dos vários processos da empresa; 


* Mapear todos os processos organizacionais existentes para in- 
cluí-los no escopo de certificação da NBR ISO 9001. 


2 - Critérios de Aceitação 
* Manual da qualidade aprovado pela alta direção da empresa; 


e Processos de auditorias internas com 90% dos itens conforme 
na primeira auditoria de avaliação; 


* Adequação do manual da qualidade aos processos organizacio- 
nais mais importantes da empresa; 


* Otimizar o processo de gestão através da implantação do siste- 
ma de gestão ISO 9001; 


* | 100% da força de trabalho treinada e capacitada nos processos 
organizacionais existentes na empresa; 


e Formatação dos procedimentos operacionais padrões conforme 
modelo proposto pela organização. 


3 - Exclusões do Projeto (não faz parte do projeto) 


e Realização das auditorias de manutenção após a certificação no 
sistema de gestão da qualidade; 


e Garantirque1 00%dos clientes estejam satisfeitos naprimeira pes- 
quisa de satisfação após a obtenção do certificado de qualidade. 


Após a elaboração da declaração do escopo do projeto, será efetuada 
a subdivisão do escopo do projeto em componentes menores e mais 
fáceis de serem gerenciados. Para isso será utilizado o Work Breakdo- 
wn Structure (WBS) ou Estrutura Análitica do Projeto (EAP), que é um 
agrupamento dos componentes do projeto, orientados para o resultado 
principal, que organiza e define o escopo total do projeto. O WBS repre- 
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senta as entregas de um projeto e o trabalho a ser feito para realizar essas 
entregas. Qualquer trabalho que não esteja incluído na WBS está fora do 
escopo do projeto. Qualquer trabalho que não possa ser identificado na 
WBS requer autorização para prosseguir, seja como uma omissão reco- 
nhecida ou como um pedido de alteração aprovado. 


A WBS define o trabalho de um projeto em termos de entregas e as fases 
do processo apropriadas para a organização do projeto. E, também, a 
base para estabelecer todas as etapas/tarefas, esforços, custos e respon- 
sabilidades em um projeto. A WBS pode ser comparada à fundação de 
um edifício. Se a fundação é boa, a chance de o edifício desabar é peque- 
na. Da mesma forma, a elaboração de uma boa WBS pode significar que 
o projeto terá maiores chances de ser finalizado com sucesso. 


Tenha em mente que: a) uma boa WBS é importante para definir o es- 
copo de um projeto; b) a WBS é a principal entrada para a criação do 
cronograma do projeto, orçamento e plano de risco; c) quanto mais você 
envolver sua equipe na criação da WBS, mais eles entenderão o escopo 
do projeto e seu papel na entrega. 


As principais funções para elaborar uma WBS são: a) delimitar e elucidar 
o escopo do projeto; b) facilitar a identificação das fases do projeto; c) 
facilitar a identificação dos responsáveis; d) orientar a identificação e 
descrição detalhada das entregas do projeto; e) identificar as atividades 
do projeto; f) facilitar a estimativa de esforço, de duração e de custo do 
projeto; g) facilitar a identificação de riscos do projeto. 


Não existe uma forma padrão para elaboração da WBS. Ela pode ser elabora- 
da por equipes, por fases, por entregas, sendo que cada uma dessas formas 
possui vantagens e desvantagens que estão demonstradas no quadro 2. 


Tipo de preparação Vantagens Desvantagens 
da WBS 
Por fases * Oferece uma visão “cro- | * Pode ofuscar a visão das 
nológica” dos aconteci- | partes necessárias para 
mentos no projeto; uma entrega específica; 
* Facilita o entendimento | * Tende a incentivar que se 
de pessoas leigas; incluam atividades admi- 
e Facilita o posterior geren- |  nistrativas (ex.: Controle 
ciamento das atividades. | do projeto). 
Por entregas * Visualiza claramente as |º* Não oferece visão 
partes que compõem o| cronológica 
projeto; 


e Facilita a discussão de 
soluções técnicas e ca- 
minhos alternativos; 

e Facilita identificação de 
riscos técnicos. 


Por equipes * Ótima para ocasiões em | * Não mostra cronologia 
que o projeto tem equi- | nem a organização das 
pes com responsabilida- | partes das entregas. 

des muito diferentes. 


Quadro 2 - Vantagens e Desvantagens das formas de preparação da WBS 
Fonte: Elaboração própria, 2020. 


O objetivo de elaborar a WBS é utilizá-la como uma ferramenta de traba- 
lho diário e não como um documento atualizado uma vez por ano para 
justificar as despesas do projeto. Para ser útil, a WBS deve ser um docu- 
mento fácil de modificar, focado em resultados definidos SMART, criado 
ou ratificado pela equipe responsável pela implementação do projeto ou 
pelas pessoas que devem prestar contas sobre seus resultados. A WBS 
não deve chegar ao patamar das atividades (a definição e gerenciamento 
das atividades são realizadas no cronograma), mas deve permanecer em 
um patamar superior, denominado pacote de trabalho”. 


As principais vantagens para se elaborar a WBS são, segundo Golany e 
Shtub (2001, p.1271)º: 


* AWBS reflete os objetivos do projeto quando lista todas as ativida- 
des necessárias para realizar estes objetivos, evitando assim confu- 
sões e dúvidas quanto ao objetivo do projeto; 


* | AWBS cria um banco de dados comum e um dicionário de notações 
comuns que servem como um ponto de referência para todas as par- 
tes interessadas no projeto; 


*  AWBS, em conjunto com o organograma do projeto, define a forma 
como o projeto deve ser gerenciado, quando relaciona cada atividade 
de trabalho à unidade organizacional correspondente que é respon- 
sável por entregar o trabalho; 


* | AWBS permite comunicações suaves entre os membros da equipe 
do projeto e entre eles e os clientes, fornecedores, reguladores, etc.; 


* | AWPBS serve como um arquivo que pode mais tarde facilitar a trans- 
ferência de conhecimento para outros projetos ou a aprendizagem 
para os novos membros da força de trabalho; 

*  AWPBS é uma ferramenta eficaz para gerenciamento dos recursos. 


As principais desvantagens segundo Golany e Shtub (2001, p.1271) são: 


*  AWPBS requer um esforço significativo para construir e manter; 


6 As metas SMART são indicadores que utilizam os seguintes princípios básicos para sua formu- 
lação: Específicos (Specific); Mensuráveis (Measurable); Atingíveis (Achievable); Relevantes (Rele- 
vant); Delimitados no tempo (Time-bound). 


7 O pacote de trabalho, último nível na discriminação da WBS é aquele cuja duração e custo podem 
ser estimados e que pode ser monitorado e controlado. Outra característica do pacote de trabalho é 
que o mesmo pode ser utilizado para designar um responsável. 


8 GOLANY, Boaz. SHTUB, Avraham. Handbook of Industrial Engineering: Technology and Opera- 
tions Management, Third Edition. Edited by Gavriel Salvendy Copyright O 2001 John Wiley & Sons, In. 
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* | AWPBS incentiva uma estrutura rígida para o projeto. Assim, reduz a 
flexibilidade gerencial para iniciar e liderar mudanças durante o ciclo 
de vida do projeto. 


Mas, quais são os passos para se elaborar um boa WBS? Essa resposta 
não é tão simples, pois depende de vários fatores como experiência do 
gestor de projetos, experiência da equipe de projetos, nível de conheci- 
mento das características do projeto, dentre outras. 

A equipe do projeto inicia a discriminação das atividades, começando 
pelo objetivo final do projeto até chegar ao nível de pacotes de trabalho. 
A estrutura a seguir facilita a ordem dos diversos níveis da WBS: 


1. Objetivo do projeto: o impacto esperado dos componentes do projeto; 


2. Componentes: o conjunto de produtos agrupados conforme sua 
natureza; 


3. Produtos: o resultado agregado dos entregáveis do projeto; 


4. Entregáveis: os serviços, bens e trabalhos produzidos pelo projeto 
através da execução dos pacotes de trabalho; 


5. Pacotes de trabalho: os grupos de atividades ou tarefas para obter os 
entregáveis do projeto. É o nível mais baixo da WBS. 


A figura 6 é um exemplo de uma WBS, seguindo a estrutura proposta 
Os passos para se elaborar uma WBS são os seguintes: 


Componente3 


Produto 3.2 


Figura 6 - WBS segundo modelo proposto 
Fonte: Elaboração própria. 


1) Colocar no primeiro nível da WBS o objetivo do projeto; 


2) Colocar no segundo nível (também chamado de primeiro nível de 
decomposição) as fases que estabelecem o ciclo de vida do projeto. 
Esta decomposição inicial, pode ser também por subprodutos, por 


sistema funcional, por localização física, por unidade administrativa 
a executar ou até mesmo por cliente; 


3) Acrescentar um elemento, no segundo nível, à esquerda, para conter 
os deliverables necessários ao gerenciamento do projeto (Iniciação, 
Planejamento, Monitoramento e Controle) e à direita, para o encer- 
ramento do projeto; 


4) Identificar os subprodutos necessários para que seja alcançado o su- 
cesso do projeto em cada fase, inclusive os relativos ao gerenciamento 
do projeto (ou outra forma de decomposição citada acima no item 2); 


5) Para cada subproduto, verificar se as estimativas de custo e tempo, 
assim como a identificação de riscos, podem ser desenvolvidas neste 
nível de detalhe e se é possível atribuir a responsabilidade para a 
execução do mesmo. Se a resposta for negativa, decompor o ele- 
mento da WBS, subdividindo-o em componentes menores, mais 
manejáveis, até que os subprodutos estejam definidos em detalhes 
suficientes para suportar o desenvolvimento dos processos de geren- 
ciamento do projeto (planejar, executar, controlar e encerrar); 


6) Rever e refinar a WBS até que o planejamento do projeto possa ser 
completado. 


A WBS não possui muitos detalhes sobre os pacotes de trabalho além 
de alguns fatores para identificação, como nome e código. Portanto, 
além da WBS, é necessário criar um documento que explique em deta- 
lhes cada elemento contido nela. Esse documento se chama dicionário 
da WBS. 


O dicionário da WBS inclui a descrição do pacote de trabalho, o respon- 
sável por ele, os participantes e os critérios de aceitação. Ele pode ser 
consultado quando houver dúvidas sobre os pacotes a serem entregues 
e para elaborar o cronograma do projeto. 


Para facilitar a localização dos “verbetes” no dicionário da WBS, cada 
elemento pode conter um código identificador (1, 1.1, 1.1.1,2,2.1,2.2, 
e assim sucessivamente). Assim, os elementos podem ser encontrados 
na WBS e no dicionário por meio dos códigos que os referenciam. 


A figura 7 apresenta um exemplo de uma WBS para gerenciar um projeto 
de uma festa de formatura. Nesse exemplo a decomposição do escopo 
do projeto foi feito de forma híbrida, associando as principais entregas 
com o ciclo de vida do projeto. 
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Figura 7 - WBS para uma festa de formatura 
Fonte: Elaboração própria, 2020 


Outro exemplo de uma WBS pode ser observado na Figura 8, que apre- 


senta a WBS para execução de um plano de marketing. 


Figura 8 - WBS para execução de um plano de marketing 
Fonte: elaboração própria, 2020. 


A Figura 9 apresenta um modelo para um dicionário da WBS para os dois 


primeiros componentes da WBS da festa de formatura. 


Critérios de 


Atividade Descrição Responsável | Participantes a 
Aceitação 
Escolher | Escolher a par- | Jussara Maria Luiza | Fornecedor de- 
fornecedor | tir do envio de | Vargas Almeida verá compro- 
para foto- | solicitações de var através de 
grafia e fil- | propostas e or- Jonathan cartas de apre- 
magem çamentos. Alvarez sentação a sua 
idoneidade. 
Enviar no mí- Felipe 
nimo 3 pro- Augusto Fornecedor que 
postas para 3 Damasceno | apresente orça- 
fornecedores mento no va- 
diferentes com lor máximo de 
as mesmas R$20.000,00 
condições de 
fornecimento. 
Contratar | Após a escolha | Jussara Maria Luiza | Contrato assina- 
fornecedor | do fornecedor | Vargas Almeida do por todas as 
para foto-| de fotografia e partes envolvi- 
grafia e fil- | filmagem, ela- Jonathan das e registrado 
magem borar o contra- Alvarez em cartório. 
to de forneci- 
mento e assinar. Felipe 
Augusto 
Fazer o registro Damasceno 
do contrato em 
cartório. 
Escolher|Visitar 6 pos- | Matheus Augusto Proposta que 
local para |síveis | locais | Felipe Fernandez tenha orça- 
realização |onde poderá | Tenório mento de até 
da festa de | ser realizada a 20.000,00 por 
formatura | | festa. pessoa para no 
máximo de 30 
Escolher a par- convidados por 
tir do envio de aluno. 
solicitações de 
propostas e or- Locais que 
çamentos. comportem no 
mínimo 1000 
Enviar no mí- pessoas. 
nimo 3 pro- 
postas para 3 
fornecedores 
diferentes com 
as mesmas 
condições de 
fornecimento. 
Contratar | Após a escolha | Matheus Augusto Contrato assina- 
local para | do fornecedor | Felipe Fernandez do por todas as 
realização | do local, elabo- | Tenório partes envolvi- 
da festa de | rar o contrato das e registrado 
formatura | de fornecimen- em cartório. 


to e assinar. 


Fazer o registro 
do contrato em 
cartório. 


Figura 9 - Dicionário da WBS 
Fonte: Elaboração própria 
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3.2.2 Definição das atividades que serão desenvolvidas no projeto 


Nessa etapa do processo, o gestor e sua equipe definirão as atividades 
que devem ser realizadas para a implementação do projeto. O tamanho 
do projeto influi diretamente no desempenho desta etapa, pois um pro- 
jeto maior demandaria uma maior mobilização de pessoal, ou até mes- 
mo a definição destas atividades por grupos distintos para uma melhor 
execução das mesmas, diferentemente de um projeto de menor escala. 


O ponto de partida para a definição das atividades é a própria WBS do 
projeto. A partir dos pacotes de trabalho definidos, parte-se para o de- 
talhamento das atividades que devem ser desenvolvidas (tarefas) para 
entregar os vários pacotes de trabalho descritos na WBS. Esse detalha- 
mento terá como resultado uma listagem com todas as atividades que 
deverão ser desenvolvidas para que o projeto seja finalizado. 


A figura 10 apresenta um exemplo de uma lista de atividades para a exe- 
cução de um plano de marketing. 


Nome da tarefa Tipo 
1. Elaborar o Plano de Marketing Objetivo do Projeto 
1.1 Análise do Mercado Pacote de Trabalho 
1.1.1 Definir público-alvo Tarefa 
1.1.2 Analisar divisão do mercado Tarefa 
1.1.3 Analisar forças e fraquezas do produto Tarefa 
1.2 Análise da Concorrência Pacote de Trabalho 
1.2.1 Analisar pontos fortes e fracos Tarefa 
1.2.2 Posicionar produto para cada concorrente Tarefa 
1.2.3 Avaliar oportunidades e ameaças Tarefa 
1.3 Análise do mercado finalizada Marco? 
1.4 Definição de Metas Pacote de Trabalho 
1.4.1 Definir volume de vendas no primeiro ano Tarefa 
1.4.2 Definir participação no mercado no primeiro ano Tarefa 
1.5 Definição de metas concluído Marco 


9 Milestones ou Marcos são pontos significativos do projeto, eventos cuja ocorrência precisa ser 
reportada às partes interessadas — stakeholders — de modo a terem clara visibilidade do seu cumpri- 
mento. Existem diferentes tipos de marcos, mas pode-se citar três tipos de marcos mais utilizados 
que são: a) marcos executivos que serão utilizados para reportar o status do projeto para executivos 
(gerentes, diretores e sócios); b) marcos financeiros que são aqueles que mapeiam os momentos de 
desembolso financeiro; e c) marcos-chaves que são aqueles que mostram pontos importantes como 
o “Fim do Planejamento”, “Disponibilização de Recursos”, “Conclusão do Design”. Esses prazos 
importantes em uma programação de um projeto são destacados por pontos específicos no tempo. 
Essas são atividades atemporais, geralmente no início ou no final de uma fase ou estágio e são usa- 
das para fins de monitoramento ao longo da vida do projeto. Frequentemente, os marcos são usados 
para atuar como pontos de gatilho para pagamentos em andamento ou prazos para recebimento 
de informações vitais, autorizações ou entregas de equipamentos. Os marcos são representados 
graficamente por meio de um triângulo ou diamante. 


1.6 Planejamento dos Canais de distribuição Pacote de Trabalho 
1.6.1 Definir canais de distribuição Tarefa 
1.6.2 Definir estratégias e políticas de distribuição Tarefa 
1.6.3 Selecionar os canais de distribuição Tarefa 
1.6.4 Definir os preços para revenda Tarefa 
1.7 Planejamento dos canais de distribuição finalizado Marco 
1.8 Estratégias de Comunicação Pacote de Trabalho 
1.8.1 Definir mensagens de acordo com o público alvo Tarefa 
1.8.2 Definição de calendários editoriais Tarefa 
1.8.3 Palestras e Workshops estratégicos Pacote de Trabalho 
1.8.3.1 Definir cronograma de palestrasAworkshops Tarefa 
1.8.3.2 Ministrar evento de lançamento do produto Tarefa 
1.8.3.3 Ministrar palestras e workshops estratégicos Tarefa 
1.8.4 Planejamento da campanha publicitária Pacote de Trabalho 
1.8.4.1 Contatar veículos de propaganda Tarefa 
1.8.4.2 Definir campanha publicitária Tarefa 
1.8.4.3 Análise do programa publicitário Tarefa 
1.8.4.4 Obter aprovação da campanha publicitária Tarefa 
1.8.4.5 Campanha publicitária aprovada Marco 
1.8.4.6 Selecionar canais de veiculação Tarefa 
1.8.4.7 Comprar material de publicidade Tarefa 
1.8.4.8 Conferir material de publicidade Tarefa 
1.8.4.9 Veiculação Comercial na Mídia Tarefa 
1.9 Estratégias de Comunicação finalizadas Marco 
2 Plano de Marketing Finalizado Marco 


Figura10 - Lista de Atividades para execução de um plano de marketing 
Fonte: Elaboração própria, 2020. 


3.2.3 Definição das estimativas da duração das atividades do projeto 


A definição das estimativas da duração das atividades do projeto é a es- 
timativa do número de períodos de trabalho (prazos) que serão neces- 
sários para complementar as atividades previstas para a realização do 
projeto. 


Tomando-se como dado de entrada para iniciar o processo de estimar 
as durações da atividade, o gerente e a equipe de projetos utilizar-se-ão 
da lista de pacotes de trabalho identificados na estrutura analítica do 
projeto (que corresponde ao nível mais baixo da WBS). As técnicas mais 
frequentes para fazer a estimativa da duração das atividades são: 


1. Parecer de especialistas: Com base em experiências anteriores, os 
especialistas podem fornecer tempos estimados de duração. A técni- 
ca é útil para as atividades nas quais a equipe tem bastante experiên- 
cia em projetos similares; 


2. Estimativa análoga: E uma técnica para estimar a duração ou o cus- 
to de uma atividade ou um projeto mediante o uso de informações 
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históricas. Utiliza parâmetros de um projeto similar, como a duração, 
o orçamento e a complexidade. Geralmente, é menos cara que as 
outras técnicas, mas também é menos exata; 


3. Estimativa paramétrica: Utiliza uma relação estatística entre dados 


históricos e outras variáveis para calcular uma estimativa de parâme- 
tros de uma atividade como o custo e a duração, por exemplo, ho- 
ras-nomem ou metros quadrados. Com tal técnica, é possível obter 
níveis mais altos de exatidão, contudo ela é mais demorada e cara; 


4. Estimativa por três valores: Pode-se obter uma exatidão maior, le- 


vando em conta o grau de incerteza e o risco. Para determinar a es- 
timativa, utiliza-se o método PERT'º, que calcula a duração esperada, 
utilizando três estimativas de tempo. A duração real usada é calcula- 
da a partir da expressão conhecida como distribuição P. 

DE = (to + 4tm + tp)/6 

Onde: 

DE = duração esperada 

to = duração otimista 

tm = duração mais provável (realista) 

tp = duração pessimista. 


SAIBA MAIS 
CÁLCULO DAS ESTIMATIVAS DE DURAÇÃO DAS ATIVIDADES 


Lembre-se de que a estimativa de duração para cada atividade é o 
tempo total decorrido desde seu início até sua finalização. Em proje- 
tos para os quais há alto grau de incerteza em relação às estimativas 
de duração das atividades, é possível usar três estimativas para cada 
atividade: 


1. Tempo otimista (to) é o tempo no qual uma atividade em particu- 
lar pode ser concluída se tudo sair perfeitamente bem e não hou- 
ver complicações. Uma regra prática é que deve haver apenas 
uma chance em dez de se concluir a atividade em menos tempo 
do que a estimativa otimista. 


10 Program Evaluation and Review Technique (PERT) - O método PERT traz grandes vantagens para 
o gerenciamento de projetos, pois auxilia no planejamento, programação, coordenação e controle 
do projeto, evitando ou minimizando o risco dos efeitos advindos de uma ocorrência inesperada ou 
acidental durante a execução do projeto. (CUKIERMAN, 2000). Na análise PERT, a distribuição do 
tempo de atividade é considerada uma distribuição beta, e a média e a variância do tempo de ati- 
vidade são estimadas com base nos tempos de conclusão “pessimista”, 'mais provável" e “otimista”, 
que são subjetivamente determinado por um ou mais analistas. CUKIERMAN, Zigmundo Salomão. 
O modelo PERT/CPM aplicado a projetos. 7º ed. Rio de Janeiro: Riechmann & Affonso Ed., 2000. 


2. Tempo mais provável (tm) é o tempo pelo qual uma atividade 
em particular pode geralmente ser completada sob condições 
normais. Se uma atividade foi repetida muitas vezes, a duração 
real que ocorre com mais frequência pode ser usada como a 
estimativa de tempo mais provável. 


3. Tempo pessimista (tp) é o tempo no qual uma atividade em par- 
ticular pode ser concluída sob condições adversas, como na 
presença de complicações incomuns ou imprevistas. Uma regra 
prática é que há apenas uma chance em dez de se concluir a ati- 
vidade em mais tempo do que a estimativa de tempo pessimista. 


O estabelecimento de três estimativas de tempo possibilita levar a 
incerteza em consideração ao se estimar quanto tempo cada ativida- 
de levará. O tempo mais provável deve ser maior ou igual ao tempo 
otimista e o tempo pessimista deve ser maior ou igual ao tempo 
mais provável. 


Não é necessário que três estimativas de tempo sejam feitas para 
cada atividade. Se alguém tiver vasta experiência ou dados de quanto 
tempo demorou a execução de atividades bastante semelhantes em 
projetos já concluídos, pode ser preferível fazer apenas uma estima- 
tiva de quanto tempo se espera de uma atividade. Contudo, usar três 
estimativas de tempo (to, tm e tp) pode ser útil quando houver alto 
grau de incerteza sobre quanto tempo uma atividade pode levar. 


SAIBA MAIS 
o que é a distribuição 


No planejamento de rede, quando três estimativas de tempo são 
usadas para cada atividade, assume-se que as três estimativas se- 
guem uma distribuição beta de probabilidades. 


Com base nessa suposição, é possível calcular uma duração espe- 
rada (também chamada de média), DE, para cada atividade, a partir 
das três estimativas de tempo. 


A figura 11 apresenta a configuração gráfica de uma distribuição p. 


4 


To Tm Tp 
Figura 11 - Representação de uma distribuição p 
Fonte: Elaboração própria, 2020 
Onde: to = duração otimista 
tm = duração mais provável (realista) 
tp = duração pessimista. 
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3.2.4 Sequenciamento das atividades que serão desenvolvidas no 
projeto e definição do caminho crítico 


Com a lista de atividades definida, sequenciar as tarefas do projeto será 
a próxima atividade. Sequenciar é identificar e documentar as relações 
de dependências entre as atividades.Para criar essa sequência de tarefas 
é preciso observar a hierarquia que há entre elas, representada na WBS: 
quais tarefas precisam ser executadas primeiro (predecessoras), quais 
precisam ser executadas depois de uma outra tarefa (sucessoras) e quais 
podem ser executadas paralelamente. Essas tarefas também precisam 
ser detalhadas, ou seja, é preciso descrever o que precisa ser feito em 
cada uma delas. Esse detalhamento precisa ser feito em um nível ideal: 
muitos detalhes podem confundir as partes envolvidas e detalhes de me- 
nos podem dificultar a compreensão do que precisa ser executado. 


Para se estabelecer as sequências de realização das atividades é impor- 
tante entender que cada uma das atividades pode ser classificada de 
acordo com o seu tipo de dependência (arbitrária, obrigatória e externa). 
As atividades que têm dependências obrigatórias são aquelas inerentes à 
natureza do trabalho que será executado. São também chamadas de rela- 
ções lógicas rígidas (hard logic). As atividades que têm dependências ar- 
bitrárias são aquelas definidas pela equipe de gerenciamento do projeto. 
Elas geralmente são definidas com base no conhecimento de melhores 
práticas, características dos projetos. Também são chamadas de relações 
lógicas preferidas, lógica flexível ou lógica preferencial. Por fim, existem 
as atividades que envolvem atividades do projeto com atividades fora do 
projeto e são chamadas de dependências externas. 


O objetivo do sequenciamento das atividades é obter o máximo de efici- 
ência dadas as características das atividades e restrições dos projetos, já 
que todas as atividades do projeto devem ser conectadas entre si. 


Vários fatores podem afetar e influenciar em como as atividades serão 
sequenciadas e os tipos de relacionamentos entre elas. Pode-se citar 
dentre vários fatores: a) características das atividades; b) listas de mar- 
cos; c) especificação do escopo do projeto; d) regras governamentais ou 
padrões de mercado; e) premissas e restrições do projeto. 


O método mais utilizado para realização do sequenciamento das ativi- 
dades de um projeto é o método do diagrama de precedência. Ele é uma 
técnica que permite visualizar a dependência entre as atividades e definir 
o tempo total para execução do projeto. As atividades são ligadas grafi- 
camente por relacionamentos lógicos, para representar a sequência em 
que devem ser executadas. Esse método possui quatro possíveis tipos de 
dependências/relacionamentos lógicos. Nas definições e exemplos abai- 
xo a letra A é usada para referenciar a atividade predecessora e a letra B 
para referenciar a atividade sucessora. 


a) 


Término para Início (TI) — o início da atividade sucessora (B) depen- 
de da conclusão da atividade predecessora (A). Nesse caso a data de 
término da atividade (A) será a data de início da atividade (B). Isso 
quer dizer que a atividade sucessora (B) poderá iniciar a qualquer 
momento depois que a atividade predecessora (A) tenha sido con- 
cluída, não necessariamente no mesmo momento ou no mesmo dia. 
Esse é o tipo de relacionamento mais comum usado nos projetos, 
diz-se que aproximadamente 95% das atividades de um projeto são 
relacionadas da forma Término para Início, onde parte ou total de 
uma atividade deve estar completa para que outra atividade possa 
iniciar. Muitos softwares de gerenciamento de projetos, como por 
exemplo, o Microsoft Project, assumem como padrão este tipo de 
relacionamento quando você preenche a coluna de “predecessor” 
ou “sucessor”. Um exemplo que representa essa configuração é que 
para realizar a amostragem e a coleta de dados em uma pesquisa de 
mercado, só se consegue iniciar a coleta de dados, após a definição 
da amostragem que será utilizada. 


Atividade Predecessora Atividade Sucessora 


Início para Início (II) — o início da atividade sucessora (B) depen- 
de do início da atividade predecessora (A). Neste tipo de relaciona- 
mento uma atividade sucessora (B) não pode ser iniciada até que 
a atividade predecessora (A) também tenha sido iniciada. São nor- 
malmente atividades que serão em paralelo, porém o início de uma 
depende do início de sua predecessora. Presta atenção para o fato 
de que o início da atividade sucessora depender da predecessora 
não quer dizer que as duas atividades devam iniciar exatamente no 
mesmo momento. Por exemplo, uma atividade (B) pode iniciar uma 
semana depois que a atividade (A) iniciou, o que não pode ocorrer 
é a atividade (B) iniciar antes de sua atividade predecessora (A). Um 
exemplo que representa essa configuração acontece quanto em um 
projeto para elaboração de um estudo de viabilidade a pesquisa de 
mercado só pode iniciar após o início do estudo de viabilidade. 


Atividade Sucessora 


Atividade Predecessora 
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(o) 


Término para Término (TT) — a conclusão da atividade sucessora 
(B) depende da conclusão da atividade predecessora (A). Em outras 
palavras, uma atividade sucessora (B) não pode ser concluída até que 
a atividade predecessora (A) seja concluída. São normalmente ativi- 
dades que serão executadas ao mesmo tempo, porém a conclusão de 
uma depende da conclusão de sua predecessora. No relacionamento 
Término para Término as duas atividades podem, mas não devem 
terminar necessariamente no mesmo momento ou no mesmo dia, o 
relacionamento apenas faz a restrição de que uma atividade sucesso- 
ra (B) só possa ser concluída ou ser dada como concluída depois que 
sua atividade predecessora (A) tenha sido concluída. 


Atividade Predecessora 


Atividade Sucessora 


Início para Término (IT) - Neste tipo de relacionamento uma ativi- 
dade sucessora (B) não pode ser concluída até que atividade prede- 
cessora (A) tenha sido iniciada. Este relacionamento normalmente é 
o mais difícil de entender, pois confunde a mente pensar que uma 
atividade (B) só termina depois que a atividade (A) anterior começa, 
parte-se sempre do pressuposto que a atividade predecessora, ou 
seja, a que vem antes seja iniciada também antes da atividade suces- 
sora, o que não pode não ser sempre verdade. Veja que a atividade 
sucessora (B) não deve obrigatoriamente terminar exatamente no 
mesmo momento ou dia em que a atividade predecessora (A) iniciar, 
ainda que atividade (B) termine alguns dias depois, o importante é 
que ela só seja dada como completa depois que sua atividade prede- 
cessora (A) tenha sido iniciada. 


Atividade Predecessora 


Atividade Sucessora 


Depois que a sequência de tarefas estiver criada, é o momento de definir 
quais serão as atividades críticas do projeto. Para isso se utiliza a técnica 
do caminho crítico (Critical Path Method - CPM). O caminho crítico é 
aquele que vai do início ao fim do projeto e leva mais tempo do que os 
outros caminhos. Também é o caminho que não tem espaços ou folgas 
de tempo entre as atividades, ou seja, neste caminho, qualquer demora 


nas atividades provocará um atraso no projeto. O cálculo dos valores 
para encontrar o caminho crítico é um processo complexo, uma vez que 
é preciso determinar a duração de cada atividade em relação às esti- 
mativas que incluem os tempos de folga para o início e a conclusão da 
atividade. O uso de programas informatizados pode facilitar o processo, 
principalmente em projetos de grande magnitude. 


Para encontrar o caminho crítico do projeto é necessário identificar os 
seguintes dados de cada uma das tarefas existentes no projeto: 


a) PDI- Primeira Data de Início: também chamada de início mais cedo 
(early start) é a data em que a atividade pode começar se todas as 
antecessoras forem executadas no prazo; 


b) PDT — Primeira Data de Término: também chamada de término 
mais cedo (early finish) é a data de término de uma atividade que 
começa em PDlI e termina no prazo; 


c) UDI - Última Data de Início: também chamada início mais tarde 
(late start) é a data limite de início de uma atividade para que ela 
possa ser concluída em UDT; 


d) UDT - Última Data de Término: também chamada de término mais 
tarde (late finish) é a data limite de uma atividade ser concluída, sem 
atrasar o projeto; 


e) Folga livre: é a folga disponível em uma atividade, tal que não pre- 
judica as PDI de suas predecessoras (é calculada por PDI sucessora 
— PDT atividade — 1); 


f) Folga total: é a folga de uma atividade igual ao somatório de sua 
folga livre com a folga livre de suas sucessoras que levam ao final do 
projeto. 


Tomando-se como base o projeto simplificado de desenvolvimento de 
um software, apresentado na figura 12, pode-se definir o caminho crítico 
desse projeto. Para isso é importante já ter definido as tarefas/atividades 
que serão desenvolvidas, a duração de cada uma das tarefas/atividades e 
as relações de dependência entre as tarefas/atividades. 


(em dias) 
1 Definição do Problema 30 - 
2 Estudo do Sistema Atual 30 1 
3 Definição de Exigências dos Usuários 60 1 
4 Concepção do Sistema Lógico 90 3 
5 Concepção do Sistema Físico 60 2 
6 Desenvolvimento do Sistema 120 4,5 
7 Testes do Sistema 60 6 
8 Converter Base de Dados 60 4,5 
9 Conversão do Sistema 60 7,8 


Figura 12 - Etapas para desenvolvimento de um software - modelo simplificado 
Fonte: elaboração própria, 2020 
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Observa-se que para o projeto exemplo apresentado na figura 12 a “ati- 
vidade 1 - definição do problema” não depende de ninguém para seu 
início. Isso significa que a atividade 1 poderá ser iniciada no momento 
“Zero” do projeto, ou seja, a atividade 1 possui como tempo mais cedo 
de início (PDI), o instante zero. A partir daí consideramos o tempo de du- 
ração de cada atividade para determinar o tempo mais cedo de término. 


Para se definir o caminho crítico, as datas mais cedo para início e térmi- 
no devem ser calculadas, assim como as datas mais tarde para início e 
término de cada uma das tarefas/atividades do projeto, conforme apre- 
sentado na figura 13 - Tabela de Precedência. 


Código | Atividade | Duração | Precedência | PDI | PDT | UDI | UDT | FOL 
(em dias) 
1 Definição 30 - 0 30 0 30 0 
do 

Problema 
2 Estudo do 30 1 30 60 | 90 | 120 | 60 
Sistema 
Atual 
3 Definição 60 1 30 90 | 30 90 0 
de Exigên- 
cias dos 
Usuários 
4 Concepção 90 3 90 |180 | 90 | 180 0 
do Siste- 
ma Lógico 
5 Concepção 60 2 60 | 120 |120 | 180 | 60 
do Siste- 
ma Físico 
6 Desenvol- 120 4,5 180 | 300 | 180 | 300 0 
vimento 
do Sistema 
7 Testes do 60 6 300 | 360 | 300 | 360 0 
Sistema 


8 Converter 60 4,5 180 | 240 | 300 | 360 | 120 
Base de 
Dados 


9 Conversão 60 7,8 360 | 420 | 360 | 420 0 
do Sistema 


Figura 13 - Tabela de precedência 
Fonte: elaboração própria, 2020 


Observações: 

PDI - Primeira Data de Início ou Início mais cedo 

PDT - Primeira Data de Término ou Término mais cedo 
UDI - Última Data de Início ou Início mais tarde 

UDT - Última Data de Término ou Término mais tarde 
FOL - Folga Livre 


Para se chegar aos valores observados na figura 13, a linha de raciocínio 
utilizada é a seguinte: 


Defina a PDI da atividade 1 - a PDI da(s) atividade(s) que não de- 
pendem de nenhuma outra atividade para ser iniciada. No caso do 
exemplo apresentado, a atividade 1 não depende de ninguém para 
iniciar e por esse motivo a sua PDI será igual a Zero; 


Defina a PDT da atividade 1 - a PDT da atividade 1 será igual a sua 
PDI mais a sua duração (PDI + D = PDT, onde PDI - Primeira Data 
de Início ou Início mais cedo, D será igual à Duração da atividade e 
PDT - Primeira Data de Término ou Término mais cedo). Nesse caso, 
como a atividade 1 tem duração igual a 30 dias a PDT será igual a 30; 


Defina a PDI da próxima atividade, que no caso do exemplo são as 
atividades 2 e 3, que dependem do término da atividade 1. Lembre- 
-se que, quando não informado, o tipo de relação de dependência a 
ser adotado será sempre Término para Início (TI); 


Utilizando-se a mesma linha de raciocínio a PDI das atividades 2 e 3 
será igual a 30, pois a PDT da atividade 1 é igual a 30. Somando-se 
as durações dessas duas atividades, tem-se que a PDT da atividade 2 
será igual a 60 e a PDT da atividade 3 será igual a 90; 


Defina a PDI e a PDT da atividade 4 - a PDI da atividade 4 será igual 
a PDT da atividade 3, porque a atividade 4 depende do término da 
atividade 3. Para calcular a PDT da atividade 4 basta somar a sua PDI 
(90) mais a duração da atividade 4 que é de 90 dias. Assim, a PDT da 
atividade 4 será igual a 180; 


Defina a PDI e a PDT da atividade 5 - a PDI da atividade 5 será igual 
a PDT da atividade 2, porque a atividade 5 depende do término da 
atividade 2. Para calcular a PDT da atividade 5 basta somar a sua PDI 
(30) mais a duração da atividade 5 que é de 60 dias. Assim, a PDT da 
atividade 5 será igual a 120; 


Defina a PDI e a PDT da atividade 6 - a PDI da atividade 6 será igual 
a PDT da atividade 4, porque a atividade 6 depende do término das 
atividades 4 e 5. Nesse caso, como a atividade 6 tem uma relação de 
dependência com duas atividades, que possuem diferentes PDTs, a 
escolha será feita, considerando aquela atividade que tiver a maior 
PDT, que nesse caso, será a atividade 4. Portanto, a PDI da atividade 
6 será igual a 180. Para calcular a PDT da atividade 5 basta somar a 
sua PDI (180) mais a duração da atividade 5 que é de 120. Assim, a 
PDT da atividade 6 será igual a 300; 


Defina a PDI e a PDT da atividade 7 - a PDI da atividade 7 será igual 
a PDT da atividade 6, porque a atividade 7 depende do término da 
atividade 6. Para calcular a PDT da atividade 7 basta somar a sua PDI 
(300) mais a duração da atividade 7 que é de 60 dias. Assim, a PDT 
da atividade 7 será igual a 360; 
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Defina a PDI e a PDT da atividade 8 - a PDI da atividade 8 será igual 
a PDT da atividade 4, porque a atividade 8 depende do término das 
atividades 4 e 5. Nesse caso, como a atividade 8 tem uma relação 
de dependência com duas atividades que possuem diferentes PDTs, 
a escolha será feita, considerando aquela atividade que tiver a maior 
PDT, que nesse caso, será a atividade 4. Portanto, a PDI da atividade 
8 será igual a 180. Para calcular a PDT da atividade 8 basta somar a 
sua PDI (180) mais a duração da atividade 8 que é de 60. Assim, a 
PDT da atividade 8 será igual a 240; 


Defina a PDI e a PDT da atividade 9 - a PDI da atividade 9 será igual 
a PDT da atividade 7, porque a atividade 9 depende do término das 
atividades 7 e 8. Nesse caso, como a atividade 9 tem uma relação 
de dependência com duas atividades que possuem diferentes PDTs, 
a escolha será feita, considerando aquela atividade que tiver a maior 
PDT, que nesse caso, será a atividade 7. Portanto, a PDI da atividade 
9 será igual a 360. Para calcular a PDT da atividade 9 basta somar a 
sua PDI (360) mais a duração da atividade 9 que é de 60. Assim, a 
PDT da atividade 9 será igual a 420. 


Bom. Calculadas as PDIs e as PDTs de todas as atividades do projeto, 
parte-se para calcular as UDls e as UDTs. Para isso, a linha de raciocínio 
é semelhante a realizada para calcular as PDIs e PDTs, só que, agora, 
parte-se do final do projeto até o seu início. Assim: 


a) Defina a UDT e a UDI da atividade 9 - pega-se a atividade do projeto 


que tem a maior PDT e parte-se dela para calcular as UDTs e UDls. 
Isso se deve ao fato de que a atividade que apresenta a maior PDT, 
normalmente é aquela que definirá o último dia de execução do pro- 
jeto. Dessa forma, como a atividade 9 é a que apresenta a maior PDT, 
parte-se dela para calcular a UDT e a UDI. Então, para calcular a UDT 
da atividade 9 devem ser feitas duas perguntas: 


1) Alguma atividade depende do término da atividade 9 para iniciar? 
Não existe nenhuma atividade que depende do término da atividade 
9 para iniciar, 


2) Qual será o último dia em que a atividade 9 terá que ser terminada 
para não atrasar o término do projeto e não atrasar o seu início pre- 
visto? A resposta será que o término mais tarde (UDT) da atividade 
9, para que não atrase o término do projeto, será o dia 420. Então, a 
UDT da atividade 9 será igual a 420. Para se calcular a UDI da ativida- 
de 9, basta subtrair da UDT da atividade 9 a sua duração. O resultado 
dessa subtração será igual a 360. 


Tendo-se a PDI, a PDT, a UDI e UDT da atividade 9, pode-se calcular 
a folga livre da atividade 9. Para isso, basta subtrair a UDT da PDT 
ou a UDI da PDI. Deste modo o folga livre da atividade 9 será igual 
a Zero. Isso significa que a atividade 9 faz parte do caminho crítico 
desse projeto; 


b) 


Defina a UDT e a UDI da atividade 8 - Novamente fazem-se as duas 
perguntas: 


1) Alguma atividade depende do término da atividade 8 para iniciar? 
Sim. A atividade 9 depende do término da atividade 8 para iniciar. 


2) Qual será o último dia em que a atividade 8 poderá terminar para 
não atrasar O início da atividade 9º A resposta será que o término 
mais tarde (UDT) da atividade 8, para não atrasar o início da ativida- 
de 9, será o dia 360. Então, a UDT da atividade 8 será igual a 360. 
Para se calcular a UDI da atividade 8, basta subtrair da UDT da ativi- 
dade 8 a sua duração. O resultado dessa subtração será igual a 300. 
Tendo-se a PDI, a PDT, a UDI e UDT da atividade 8, pode-se calcular 
a folga livre da atividade 8. Para isso, basta subtrair a UDT da PDT 
ou a UDI da PDI. Deste modo o folga livre da atividade 8 será igual a 
120. Isso significa que a atividade 8 não faz parte do caminho crítico 
desse projeto, pois apresenta uma folga livre de 120 dias; 


Defina a UDT e a UDI da atividade 7 - Novamente fazem-se as duas 
perguntas: 


1) Alguma atividade depende do término da atividade 7 para iniciar? 
Sim. A atividade 9 depende do término da atividade 7 para iniciar. 


2) Qual será o último dia em que a atividade 7 poderá terminar para 
não atrasar O início da atividade 9? A resposta será que o término 
mais tarde (UDT) da atividade 7, para não atrasar o início da ativida- 
de 9, será o dia 360. Então, a UDT da atividade 7 será igual a 360. 
Para se calcular a UDI da atividade 7, basta subtrair da UDT da ativi- 
dade 7 a sua duração. O resultado dessa subtração será igual a 300. 


Tendo-se a PDI, a PDT, a UDI e UDT da atividade 7, pode-se calcular 
a sua folga livre. Para isso, basta subtrair a UDT da PDT ou a UDI da 
PDI. Deste modo o folga livre da atividade 7 será igual a Zero. Isso 
significa que a atividade 7 faz parte do caminho crítico desse projeto; 


Defina a UDT e a UDI da atividade 6 - Novamente fazem-se as duas 
perguntas: 


1) Alguma atividade depende do término da atividade 6 para iniciar? 
Sim. A atividade 7 depende do término da atividade 6 para iniciar. 


2) Qual será o último dia em que a atividade 6 poderá terminar para 
não atrasar o início da atividade 7? A resposta será que o término 
mais tarde (UDT) da atividade 6, para não atrasar o início da ativida- 
de 7, será o dia 300. Então, a UDT da atividade 6 será igual a 300. 
Para se calcular a UDI da atividade 6, basta subtrair da UDT da ativi- 
dade 6 a sua duração. O resultado dessa subtração será igual a 180. 


Tendo-se a PDI, a PDT, a UDI e UDT da atividade 6, pode-se calcular 
a sua folga livre. Para isso, basta subtrair a UDT da PDT ou a UDI da 
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PDI. Deste modo o folga livre da atividade 6 será igual a Zero. Isso 
significa que a atividade 6 faz parte do caminho crítico desse projeto; 


Defina a UDT e a UDI da atividade 5 - Novamente fazem-se as duas 
perguntas: 


1) Alguma atividade depende do término da atividade 5 para iniciar? 
Sim. Nesse caso, existem duas atividades que dependem do término 
da atividade 5 para iniciar, são elas: a atividade 6 e a atividade 8. 


2) Qual será o último dia em que a atividade 5 poderá terminar para 
não atrasar o início da atividade 6 e da atividade 8? A resposta será 
que o término mais tarde (UDT) da atividade 5, para não atrasar o 
início da atividade 6 e da atividade 8, será o dia 180. Então, a UDT 
da atividade 5 será igual a 180. Para se calcular a UDI da atividade 
5, basta subtrair da UDT da atividade 5 a sua duração. O resultado 
dessa subtração será igual a 120. 


Tendo-se a PDI, a PDT, a UDI e UDT da atividade 5, pode-se calcular 
a sua folga livre. Para isso, basta subtrair a UDT da PDT ou a UDI 
da PDI. Deste modo o folga livre da atividade 5 será igual a 60. Isso 
significa que a atividade 5 não faz parte do caminho crítico desse 
projeto; 


Defina a UDT e a UDI da atividade 4 - Novamente fazem-se as duas 
perguntas: 


1) Alguma atividade depende do término da atividade 4 para iniciar? 
Sim. Nesse caso, existem duas atividades que dependem do término 
da atividade 4 para iniciar, são elas: a atividade 6 e a atividade 8. 


2) Qual será o último dia em que a atividade 4 poderá terminar para 
não atrasar o início da atividade 6 e da atividade 8? A resposta será 
que o término mais tarde (UDT) da atividade 4, para não atrasar o 
início da atividade 6 e da atividade 8, será o dia 180. Então, a UDT 
da atividade 4 será igual a 180. Para se calcular a UDI da atividade 
4, basta subtrair da UDT da atividade 4 a sua duração. O resultado 
dessa subtração será igual a 90. 


Tendo-se a PDI, a PDT, a UDI e UDT da atividade 4, pode-se calcular 
a sua folga livre. Para isso, basta subtrair a UDT da PDT ou a UDI da 
PDI. Deste modo o folga livre da atividade 4 será igual a Zero. Isso 
significa que a atividade 4 faz parte do caminho crítico desse projeto; 


Defina a UDT e a UDI da atividade 3 - Novamente fazem-se as duas 
perguntas: 


1) Alguma atividade depende do término da atividade 3 para iniciar? 
Sim. A atividade 4 depende do término da atividade 3 para iniciar. 


2) Qual será o último dia em que a atividade 3 poderá terminar para 
não atrasar o início da atividade 4? A resposta será que o término 
mais tarde (UDT) da atividade 3, para não atrasar o início da ativida- 
de 4, será o dia 90. Então, a UDT da atividade 3 será igual a 90. Para 
se calcular a UDI da atividade 3, basta subtrair da UDT da atividade 
3 a sua duração. O resultado dessa subtração será igual a 30. 


Tendo-se a PDI, a PDT, a UDI e UDT da atividade 3, pode-se calcular 
a sua folga livre. Para isso, basta subtrair a UDT da PDT ou a UDI da 
PDI. Deste modo o folga livre da atividade 3 será igual a Zero. Isso 
significa que a atividade 3 faz parte do caminho crítico desse projeto; 
Defina a UDT e a UDI da atividade 2 - Novamente fazem-se as duas 
perguntas: 


3) Alguma atividade depende do término da atividade 2 para iniciar? 
Sim. A atividade 5 depende do término da atividade 2 para iniciar. 


4) Qual será o último dia em que a atividade 2 poderá terminar para 
não atrasar o início da atividade 5? A resposta será que o término 
mais tarde (UDT) da atividade 2, para não atrasar o início da ativida- 
de 5, será o dia 120. Então, a UDT da atividade 2 será igual a 120. 
Para se calcular a UDI da atividade 2, basta subtrair da UDT da ativi- 
dade 2 a sua duração. O resultado dessa subtração será igual a 90. 


Tendo-se a PDI, a PDT, a UDI e UDT da atividade 2, pode-se calcular 
a sua folga livre. Para isso, basta subtrair a UDT da PDT ou a UDI 
da PDI. Deste modo o folga livre da atividade 2 será igual a 60. Isso 
significa que a atividade 2 não faz parte do caminho crítico desse 
projeto; 


Defina a UDT e a UDI da atividade 1 - Novamente fazem-se as duas 
perguntas: 


5) Alguma atividade depende do término da atividade 1 para iniciar? 
Sim. Nesse caso, existem duas atividades que dependem do término 
da atividade 1 para iniciar, são elas: a atividade 2 e a atividade 3. 


6) Qual será o último dia em que a atividade 1 poderá terminar para 
não atrasar o início da atividade 2 e da atividade 3? A resposta será 
que o término mais tarde (UDT) da atividade 1, para não atrasar o 
início da atividade 2 e da atividade 3, será o dia 30. Então, a UDT da 
atividade 1 será igual a 30. Para se calcular a UDI da atividade 1, bas- 
ta subtrair da UDT da atividade 1 a sua duração. O resultado dessa 
subtração será igual a O. 


Tendo-se a PDI, a PDT, a UDI e UDT da atividade 1, pode-se calcular 
a sua folga livre. Para isso, basta subtrair a UDT da PDT ou a UDI da 
PDI. Deste modo o folga livre da atividade 1 será igual a O. Isso sig- 
nifica que a atividade 1 faz parte do caminho crítico desse projeto. 
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Feitos os cálculos das PDls, das PDTs, das UDs, das UDTs e das folgas li- 
vres, pode-se analisar a tabela de precedência e tirar algumas conclusões. 


A primeira informação que se tira da tabela de precedência apresentada 
na Figura 13 é que o projeto irá durar 420 dias. 


O caminho crítico desse projeto é composto das atividades que têm 1, 
3, 4,6, 7 e 9. Nesse exemplo as atividades que compõem o caminho 
crítico não podem sofrer atrasos, porque se isso acontecer o projeto irá 
atrasar também. Se a atividade 1 atrasar dois dias em sua duração, o 
projeto, também, irá atrasar em dois dias o seu término. Igualmente, se a 
atividade 1 adiantar dois dias em sua duração, o projeto irá adiantar em 
dois dias o seu término. Essa mesma linha de análise é válida para todas 
as atividades que compõem o caminho crítico do projeto. 


O próximo passo será elaborar o cronograma do projeto. 
3.2.5 Elaboração do Cronograma do projeto 


O cronograma do projeto é uma ferramenta para realização do planeja- 
mento e do controle das atividades de um projeto e organiza as tarefas 
a serem realizadas dentro de um período de tempo para alcançar um 
objetivo final. 


O cronograma é mais do que a soma dos tempos das atividades de um 
projeto, já que apresenta toda a sequência lógica e os passos a serem 
seguidos para atingir os resultados. Considerando que o tempo é uma 
das restrições mais importantes do projeto, o cronograma se torna a 
ferramenta que o gerente de projetos e sua equipe usaram mais frequen- 
temente, não só para controlar o avanço do projeto, mas também para 
realizar a análise e os ajustes necessários. 


Ele pode ser feito no papel, em uma planilha ou até em softwares espe- 
cializados, podendo ser representado graficamente ou não, o importante 
é que todos os envolvidos tenham uma visão clara sobre os prazos e 


datas de entrega. 


Para se elaborar um cronograma são necessários os seguintes dados de 
entradas: 


a) a WBS que organiza e define o escopo total do projeto. Os trabalhos 
não incluídos na WBS ficam fora do escopo do projeto; 


b) as restrições que são os fatores que limitam as opções da equipe do 
projeto; 


c) as dependências existentes entre as atividades do projeto; 


d) as estimativas de durações das atividades; 


e) o calendário de recursos que é a disponibilidade dos recursos para 
uso do projeto; 


f) a data prevista para início ou término do projeto"; 
g) calendário"? que será utilizado para a realização do projeto. 


Se a equipe de projetos já elaborou a tabela de precedência e já definiu o 
caminho crítico dele, a montagem do cronograma será uma ótima opor- 
tunidade para revisar as informações anteriormente produzidas, confir- 
mar se elas serão mantidas e aprimorar o planejamento do projeto. Além 
disso, a elaboração do cronograma permitirá uma completa visualização 
das várias etapas que deverão ser cumpridas para que o projeto seja 
concluído com sucesso. 


O modelo mais utilizado para representar graficamente um cronograma 
de um projeto é o Gráfico de Gantt. O objetivo do Gráfico de Gantt é 
mostrar o tempo dedicado previsto para as diversas atividades ao longo 
do tempo total do projeto. 


O gráfico de Gantt é um gráfico de barras que foi originalmente inventa- 
do pelo engenheiro polonês, Karol Adamiecki, mas foi Henry Laurence 
Gantt, um engenheiro de produção americano, quem disseminou o seu 
uso no início do século XX. O gráfico de Gantt foi usado em várias aplica- 
ções de planejamento durante a Primeira Guerra Mundial e foi a principal 
ferramenta de planejamento para engenheiros de produção e construção 
até a invenção da técnica CPM. 


O Gráfico ou Diagrama de Gantt é formado por um eixo vertical, onde 
constam as atividades que constituem o trabalho a ser executado e um 
eixo horizontal, no qual se mostra a duração de cada uma delas em um 
calendário. Cada atividade é apresentada na forma de uma barra ou de 
uma linha que exibe o início e o final de cada uma, os grupos de ativi- 


11 Normalmente a montagem do cronograma é feita a partir de uma data de início e o seu planeja- 
mento seguirá uma lógica em que o início se dará a partir dessa data inicial. Mas, muitos projetos 
podem ser definidos a partir de uma data final. Assim, a elaboração do cronograma será feita a partir 
da data final para a data inicial. 


12 Os calendários de um projeto definem todo o mecanismo de agendamento, determinando pe- 
ríodos úteis e não úteis para execução das atividades, bem como disponibilidade de recursos para 
atribuições. Por exemplo, no MS Project existem três tipos de calendários: a) calendário turno da 
noite — esse calendário pode ser utilizado para escalas de trabalho de segunda-feira à noite até sába- 
do de manhã, o período de trabalho é das 23h às 8h, com uma hora de intervalo; b) calendário 24 
horas — esse calendário é contínuo, ou seja, não tem nenhum período de folga. É ideal se os recursos 
forem equipamentos que trabalham sem parar; c) calendário padrão — esse é o calendário-base, 
automaticamente utilizado pelo Project, para direcionar tarefas, recursos e o projeto como um todo. 
Possui uma agenda de trabalho convencional de segunda a sexta-feira, das 9h às 18h. 
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dades relacionados entre si e as relações de dependências entre ambas. 
Esse conjunto original de linhas é chamado de linhas de base e o progres- 
so pode ser monitorado por meio dele. Ao realizar essa representação 
gráfica para cada atividade, uma visão geral do trabalho necessário em 
um projeto pode ser vista rapidamente. O progresso de uma atividade 
pode ser registrado desenhando uma segunda linha abaixo da linha de 
base ou colorindo a linha de base para mostrar o progresso em uma base 
diária, semanal ou mensal. 


O Gráfico de Gantt pode ser útil, também, como método para aloca- 
ção dos recursos necessários para que as atividades sejam executadas. 
Quando se faz a alocação dos recursos nas atividades representadas no 
Gráfico de Gantt, ao final do processo tem-se a informação dos recursos 
totais necessários para a execução do projeto. Ao realizar essa operação 
para todos os períodos de tempo, uma série de barras verticais mostra 
quais recursos são necessários para o projeto, o que é conhecido como 
histograma de recursos. 


FERRAMENTAS DO GRÁFICO DE GANTT 
EFA RECURSO RELATÓRIO PROJETO — EXEIÇÃO FORMATO A Ricardo Thielmann - DI x 
FE Uso do Recurso » 81 classificar % [Sem Realce) =| Escala de Tempo: Q Zoom Linha do Tempo 
Er E Planilha de Recursos = BE Estrutura de Tópicos» F' SemFitro] =| [Dias = ER Proj 
detquipe= TB de bxibição  cfy Tabelas» EB [Nenhum Gru - 
Dados 


+ Têmo 

Seg 02/11/20 Qua 100224 

Seg 0211/20 Seg 0811120 

Seg 02/11/20 Qua dartirzo 

1.1.2 Anaisar coraão do mercado Qui OS/11720 Sex 06/11/20 

1,13 Analisar forças e fraquezas do pro Seg 08/11/20 Seg Osv11120 

4 1.2 Análise da Concorrência Qui 05/14720 Qua t111120 

121 Analisar pontos fortes e fracos Seg 09/11/20 Qua 11111720 

1.22 Posicionar produto para cada cone Qui OS/11/20 Sex 06/1120 

1.23 Avalar oportunidades e ameaças Sex 06/11/20 Seg Os/t120 

1.3 Análise do mercado fnalzado Qua 1UNIIZO Qua NIRO 

4 1,4 Definição de Metas. Qui 12/1420 Seg 16/1120 

1.4.1 Definir volume de vendas no primei Qui 12/11/20 Seg 16111120 

142 Defnr partepação no marcado no Sex 1311/20 Seg 16/1120 

1.5 Defiução de metas concluido Seg 18/11/20 Seg 16/1120 

4 1,5 Planejamento dos Canais de Ter 7/4920 Qua 25/1120 
distribuição 

161 Definir canais de distriuição Ter NTINNIRO Qua 18/1120 

182 Defnr estratégis e policas de dis Qui 19/11/20 Seg 23711120 

1.63 Selecionar 08 canas de destruição Qua 18711120 Seg 23/1120 

154 Definir 08 preços para revenda Ter ZUININRO Qua 25/1120 

117 Panejamento dos canas de disrbuição Qua 25/11/20 Qua 28/11/20 

1.8 Estratégias de Comunicação Qui 26/14/20 Qua 10/0221 

38] 19 Estratégias do Comunicação finaliz Qua 100221 Qua 10221 

29 2 Plano de Marketing Finalizado Qua 10802721 Que 10/0221 


E 
5! 
g: 
õ" 


Figura 14 - Gráfico de Gantt de um projeto para elaboração de um plano de marketing 
Fonte: Elaboração própria, 2020 


Até que o cronograma esteja pronto em definitivo muitas mudanças irão 
acontecer. Essas mudanças são necessárias para aprimorar o planeja- 
mento do projeto, porque a criação de um cronograma é um processo 
que exige revisões constantes das estimações a fim de se obter um pla- 
nejamento que se ajuste às restrições do projeto. 


O gerente do projeto e sua equipe deverão realizar vários ajustes até 
obter um cronograma final. Nessas revisões, algumas técnicas podem 
ser utilizadas para encurtar a duração do projeto sem comprometer as 
entregas finais. Duas técnicas são muito utilizadas: a compressão do 
cronograma e o paralelismo. A compressão (crashing) implica reduzir a 
estimativa original de uma atividade por meio do uso de recursos origi- 
nais. À relação entre os custos e a duração é analisada para determinar 


o maior grau de compressão pelo menor aumento possível nos custos. 
A compressão nem sempre produz alternativas viáveis e, muitas vezes, 
ocasiona um aumento do risco e do custo. Já o Paralelismo (fast tracking) 
significa realizar atividades de forma paralela, que normalmente seriam 
executadas em sequência, exigindo o uso de recursos adicionais. Fre- 
quentemente, essa técnica aumenta de forma desproporcional o risco 
associado ao projeto e está limitada às relações de dependência entre as 
atividades. 


3.2.6 Planejamento dos recursos necessários para execução 
das atividades do projeto 


O foco deste processo é o de definir qual o nível de qualificação e expe- 
riência necessário para a execução das atividades definidas na etapa de 
definição das atividades, bem como a alocação do pessoal com as capa- 
cidades nas respectivas tarefas. Um exemplo seria a definição do escopo 
da implementação. Definir o escopo de um projeto demanda uma maior 
experiência para seus executores devido à necessidade de uma visão 
sistêmica apurada. Por outro lado, o processo de elaboração de registros 
não demanda pessoal de elevada experiência para sua execução. 


Além da definição do pessoal serão definidos todos os outros recursos 
necessários para que as atividades sejam executadas, como máquinas, 
equipamentos, materiais de consumo e insumos. 


Essa é a primeira etapa na elaboração de um orçamento do projeto. 


3.2.7 Definição das estimativas dos custos dos recursos alocados 
nas atividades do projeto 


A definição das estimativas dos custos dos recursos é um processo em 
que o gestor de projetos juntamente com a equipe do projeto irá definir 
quais são os valores monetários dos recursos que serão alocados para 
realização das atividades definidas no projeto. A definição dessas estima- 
tivas pode ser feita por meio de opiniões de especialistas, estimativas por 
analogia, estimativas paramétricas, estimativa Bottom-up e da estimativa 
de três pontos. 


Além disso, não se deve esquecer de incluir as reservas de contingên- 
cias (algumas vezes chamadas de provisões para contingências) para 
considerar os custos das incertezas. As reservas de contingência são o 
orçamento dentro da linha de base dos custos designados para riscos 
identificados que são aceitos e para os quais respostas contingentes ou 
mitigadoras são desenvolvidas. As reservas de contingência são frequen- 
temente vistas como parte do orçamento que aborda as “incógnitas co- 
nhecidas” que podem afetar um projeto (PMBOK, 2013). 
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3.2.8 Elaboração do orçamento do projeto 


A elaboração do orçamento é um processo que começa a ser realizado 
junto com o planejamento das atividades. 


Determinar o orçamento é o processo de agregação dos custos estima- 
dos das atividades individuais ou pacotes de trabalho, para estabelecer 
uma linha de base dos custos que deverá ser autorizada. O principal be- 
nefício deste processo é a determinação da linha de base dos custos para 
o monitoramento e controle do desempenho do projeto (PMBOK, 2013). 


ATIVIDADES 


A empresa XYG Consultoria recebeu uma demanda para realização 
de uma pesquisa de mercado. Após uma reunião com os clientes, 
os consultores da empresa se reuniram e definiram como atividades 
a serem desenvolvidas as abaixo listadas. 


Código Atividade Duração | Precedência | Responsável 
(dias) 

1 Identificar 5 - Susan 
Consumidores- 
-alvo 

2 Esboçar 10 1 Susan 
Questionário 

3 Questionário 5 », Susan 
Teste Piloto 

4 Concluir 5 ê) Susan 
Questionário 

D Imprimir 5 4 Steve 
Questionário 

6 Preparar 10 1 Steve 
Etiquetas para 
mala direta 

7 Enviar questio- 30 6 Steve 
nário - coletar 
respostas 

8 Desenvolver 115 4 Andy 
Software de 
Análise de Dados 

9 Desenvolver 10 8 Susan 
Dados para Teste 
de Software 

10 || Testar software 10 9 Andy 

11 Inserir dados de 10 7;9 Jim 
resposta 

im Analisar resultados 5 Já Jim 

13 | Preparar relatório 5 12 Jim 


Vale ressaltar que a empresa XYG Consultoria trabalha, normalmen- 
te, no horário comercial (8 às 12 e de 14 às 18 horas) de segunda 
a sexta-feira. Sábados e domingos são considerados períodos de 
folga. Os consultores designados para participarem deste projeto 
serão Susan, Steve, Andy e Jim. No momento em que eles estiverem 
trabalhando neste projeto a dedicação será total. Considere que, 
para elaboração do cronograma, o projeto tenha seu início previsto 
para 06 de janeiro de 2025 (segunda-feira). 


Com base nestas informações elabore: 

A. Uma tabela de precedência que informe as PDI, PDT, UDI, UDT 
e as folgas livres das atividades; 

B. O caminho crítico deste projeto; 

C. O tempo necessário para que o projeto seja realizado, em dias 
úteis; 

D. Elabore o cronograma do projeto utilizando-se um Gráfico de 
Gantt. 


Respostas comentadas 
A) Atabela de precedência para esse projeto é a seguinte: 


Có- | Atividade Du- Pre- Res- | PDI | PDT | UDI | UDT | FOI- 
digo ração | ce- pon- GA 

(dias) | dên- | sável LIVRE 
cia 


1 Identificar | 5 - Susan | O 5 0 5 (0) 
Consu- 
midores- 
-alvo 


2 Esboçar 10 1 Susan | 5 15 5) 15 (0) 
Questio- 
nário 

3 Ques- E) 2 Susan | 15 20 its 20 0 
tionário 
Teste 
Piloto 


4 Concluir 5 3) Susan | 20 25) 20 255) 0 
Questio- 
nário 

5 Imprimir |5 4 Steve | 25 30 65 70 40 
Questio- 
nário 

6 Preparar | 10 1 Steve | 5 15 10 20 5) 
Etiquetas 
para mala 
direta 


7 Enviar 30 6 Steve | 15 45 20 50 5) 
ques- 
tionário 

- coletar 
respostas 


8 Desen- 15 4 Andy |25 40 25 40 0 
volver 
Software 
de Análise 
de Dados 


9 Desenvol- | 10 8 Susan | 40 50 40 50 0 
ver Dados 
para 
Teste de 
Software 
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10 | Testar 10 ) Andy | 50 60 |60 70 10 
software 


11 Inserir 10 7:9 Jim 50 60 50 60 0 
dados de 
resposta 


12 Analisar 5 11 Jim 60 65 60 65 0 
resultados 


116) Preparar 5 iz Jim 65 70 65 70 0 
relatório 


B) O caminho crítico deste projeto é composto pelas seguintes ati- 
vidades: 1,2,3,4, 8, 9, 11, 12, 13; 


C) O tempo necessário para que o projeto seja realizado é de 70 
dias úteis; 


D) O Gráfico de Gantt desse projeto será representado conforme a 


figura abaixo: 


[ HRREZE 


EBD ses coro resóro moro  exsção 


- salvo Séas — sego6/01/25 Sex 10/01/25 Susan " 
= st lodas Seg 13/01/25 Sex 24/01/25 1 Susan fura 
= este Séas seg27/03/25 Sex31/01/25 2 Susan Susan 
- E Séas  segoa/02/25 Sexo7/02/25 3 Susan %o Susan 
+ = es Sdias Seg 10/02/25 Sex 14/02/25 + Steve Fe Steve 
é - Prepara Etiquetas para mala direta todas — Seg13/01/25 Sex28/00/25 1 Steve 
+= Enviar questionánocoletarrespostas J0das  Seg27/03/25 Sex07/03/25 6 Steve 
- s Sofia je Dados Seg 10/02/25 sex 28/02/25 4 Andy 
E = o Seg 03/03/25 Sex 14/03/25 8 Susan usam 
E - estar O das Seg17/03/25 Sex28/03/25 9 Andy Andy 
4 - a de respos Seg 17/03/25 Sex28/03/25 79 fal pr 
E - o s Seg31/08/25 Sexoa/04/25 11 ja vm 
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3.2.9 Planejar a qualidade do projeto 


Inicialmente é importante definir o que é qualidade na atividade de pro- 
jetos. Pode-se entender por qualidade a totalidade de recursos e caracte- 
rísticas de um do produto ou serviço resultante do projeto que influen- 
ciam sua capacidade de satisfazer uma determinada necessidade. 


O sucesso de um projeto também é medido pela qualidade e pelo grau 
de satisfação dos interessados e isso requer que sejam entregues os be- 
nefícios para os quais o projeto foi empreendido. 


Para projetos empreendidos para solucionar problemas sociais, normal- 
mente a qualidade se refere à obtenção do impacto esperado pela in- 
tervenção em termos do cumprimento de metas de desenvolvimento 
econômico e social. É, portanto, um fator-chave a ser considerado para 
avaliar o sucesso do projeto. Para esses tipos de projetos específicos, 
não basta entregar um projeto que cumpra com o escopo, o tempo e o 
orçamento, também é necessário atender às necessidades e expectativas 


dos stakeholders, que são os juízes definitivos da qualidade do projeto. 
Para lidar com tais restrições, há necessidade de uma análise cuidadosa 
das prioridades para a organização, a entidade financeira e os beneficiá- 
rios finais. Dependendo desses fatores, um projeto pode enfatizar mais 
o custo e a qualidade do que o tempo e o escopo. Esse tipo de decisão 
e o estabelecimento de prioridades no início do projeto têm um impacto 
fundamental em todas as determinações e nos planos subsequentes. 


Para realizar o planejamento da qualidade do projeto usa-se um docu- 
mento chamado plano de qualidade. 


O plano de qualidade é o documento do projeto que define as ações e 
processos a serem realizados, juntamente com os pontos de espera para 
revisões e inspeções. Ele também define os documentos de controle, 
padrões aplicáveis, métodos de inspeção e autoridade de inspeção. Esta 
autoridade para realização das inspeções pode ser dada a pessoal interno 
e/ou aos clientes do projeto ou mesmo para organizações externas espe- 
cializadas na realização de inspeção e auditoria. 


O plano de qualidade é um documento específico do projeto que varia 
muito em conteúdo e tamanho de empresa para empresa. Como regra 
geral, esse documento deve ter: 


1. Os processos a serem empregados; 
2. Os pontos de espera de cada processo de produção; 


3. Os testes a serem realizados para diferentes materiais e componen- 
tes, incluindo: 
* verificações dimensionais e verificações de peso, 
* testes de materiais (físicos e químicos), 
* testes não destrutivos (radiografia, ultrassom, partícula magnética, etc.), 
* testes de pressão, 
* testes de vazamento, 
e testes elétricos (tensão, corrente, resistência, continuidade, etc.), 
* testes de qualificação e capacidade para operativos; 


4. Os documentos de controle, incluindo relatórios e pedidos de 
concessão; 


5. As normas a serem aplicadas aos diferentes componentes; 
6. O método de inspeção; 
7. A porcentagem de itens ou processos a serem verificados; 


8. Os responsáveis pelas validações, sejam internas, externas ou 
estatutárias; 


9. Os critérios de aceitação para os testes e verificações. 
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A maioria das organizações tem seus próprios padrões e procedimentos 
de teste, mas também podem ser obrigadas a cumprir os padrões de 
qualidade do cliente. Um modelo de plano de qualidade é mostrado na 
Figura 15. 


1. 


PLANO DE QUALIDADE DO PROJETO — 
<NOME DO PROJETO > 


Figura 15 - Modelo de Plano de Qualidade para projetos. 


Introdução 

Este documento define o Plano de Qualidade do projeto <nome do 
projeto>, identificando como a qualidade da aplicação, dos artefatos 
e dos processos envolvidos no progresso da solução será garantida. 


Processos a serem utilizados no projeto 

Esta seção descreve o conjunto de processos a serem utilizados no 
projeto. 

<A descrição de cada processo deve deixar claro quais os passos 
que serão dados para garantir a qualidade esperada do projeto. Esta 
descrição consiste na definição do objetivo do processo, suas ativi- 
dades e passos, possivelmente referenciando artefatos externos.> 


<Dependendo da complexidade dos processos a serem descritos 
nesta seção, uma subseção pode ser criada para cada processo. 
Entretanto, um parágrafo para cada processo poderá se mostrar 
adequado.> 


Documentação do Projeto 

<A documentação é um importante aspecto da qualidade aborda- 
do por este plano. A criação de uma lista inicial dos artefatos de 
produto e processo a serem criados estabelece um compromisso a 
ser seguido pela equipe do projeto. > 


A tabela abaixo apresenta cada artefato a ser gerado no projeto, as- 
sim como a fase em que o mesmo será elaborado pela primeira vez 
e seus respectivos responsáveis. São incluídos na tabela tanto os ar- 
tefatos a serem entregues ao cliente (produto) como os artefatos de 
processo. 


<Todos os artefatos previamente definidos devem ser listados na 
tabela abaixo. > 


Artefato | Fase em que será desenvolvido Responsáveis 
Artefato 1 Fase 2 da execução José Maria da Silva 
Artefato 2 Fase 3 da execução Cláudio Roberto Estevão 


Guias, Normas e Padrões de Qualidade 

Guias, normas e padrões de qualidade são diretrizes cujo objetivo é 
evitar a ocorrência de não conformidades do processo e dos produ- 
tos gerados em um projeto. Comumente, estas diretrizes são especi- 
ficadas por autoridades externas à organização, como a ISO. 


Di 
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A tabela abaixo lista os guias, normas e padrões de qualidade que 
devem ser obedecidos em todo o progresso da solução. 


<Algumas diretrizes são exigência direta do cliente, outras surgem 
da necessidade de haver um mecanismo auxiliar para satisfazer 
requisitos ou, por fim, como consequência do grau de maturidade 
da organização. > 


Guia / Norma / Padrão Referências 
<Guia/Norma/Padrão 1> <Esta coluna contém informações sobre 
a diretriz, possivelmente um link para sua 
especificação > 


<Guia/Norma/Padrão N> 


Métricas de Qualidade 
As métricas de qualidade apresentadas na tabela abaixo indicam pa- 
râmetros para avaliação do resultado de inspeções e auditorias. 


Métrica Possíveis valores | Interpretações Dicas para 
medição e análise 


Ex.: Número de | Qualquer núme- 


não  conformi- 
dades encontra- 
das em um item 
auditado 


ro inteiro maior 
ou igual a zero 


Qualquer valor | Avaliar o produto 


diferente de zero 
indica a necessi- 
dade de reajustar 
o item auditado 


seguindo a espe- 
cificação da nor- 
ma utilizada. 


de modo a garan- 
tir sua qualidade 


Inspeções e Auditorias 

<Inspeções e auditorias têm como objetivo a identificação de não 
conformidades tanto em produtos e como em processos. Inspe- 
ções são revisões mais informais, geralmente realizadas pela pró- 
pria equipe responsável pelo item a ser inspecionado. Em uma ins- 
peção, é considerada natural a descoberta de não conformidades 
no item inspecionado. A intenção é justamente descobrir e corrigir 
a maior quantidade de não conformidades possível antes da au- 
ditoria. Esta última, por sua vez, é caracterizada por revisões for- 
mais, mais rígidas, geralmente realizadas por uma equipe externa 
ao item a ser auditado. Ao contrário da inspeção, o encontro de 
não conformidades em uma auditoria é mais grave e contribui ne- 
gativamente para a definição do grau de qualidade do produto ou 
processo auditado.> 


Atividade Tipo Objetivo e Procedimentos Participantes 


<Ex.: Re- | <Inspeção | <Deve-se indicar o item a | <Responsáveis e 
visão de|ou Audito- | ser verificado e como isso | outros indivíduos da 


Código> [|ria> será feito. Por exemplo, a | inspeção/auditoria> 

revisão de código pode ve- 
rificar se o padrão de docu- 
mentação definido no Plano 
de Desenvolvimento está 
sendo utilizado > 
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<Um parágrafo adicional nesta seção define o meio através do qual 
os resultados de inspeções e auditorias serão registrados. Uma fer- 
ramenta de bug tracking pode ser utilizada para tal propósito.> 


7. Cronograma 
O cronograma para as atividades acima pode ser encontrado em 
<aqui deve ser inserido um link para o arquivo de cronograma do 
projeto e identificado a seção deste cronograma que corresponde 
às atividades de qualidade >. 


8. Equipe de Qualidade 
<A tabela abaixo deve ser preenchida depois que as pessoas envol- 
vidas nas atividades de qualidade forem identificadas, assim como 
suas responsabilidades. > 


<A equipe de indivíduos responsável por garantir que as diretrizes 
utilizadas pelo projeto para a garantia da qualidade (guias, normas 
e padrões) estão sendo realmente efetivas é Grupo de Garantia da 
Qualidade. Adicionalmente, este grupo é o responsável pelas audi- 
torias (e registro de seus resultados), verificando se o processo e os 
produtos gerados pelo projeto estão obedecendo a guias, normas e 
padrões de qualidade anteriormente especificados, identificando a 
existência de eventuais não conformidades no projeto e orientando a 
eliminação das mesmas. > 


Nome Responsabilidades 


<Ex.: José Silva> <Gerenciar o Grupo de Garantia da Qualidade> 


9. Referências 
<Cite aqui outros documentos do projeto ou de fontes externas 
que contribuam para a elaboração e um melhor entendimento des- 
te Plano de Qualidade> 


Fim do modelo de Plano de Qualidade 


O plano de qualidade faz parte do plano de gerenciamento do projeto e, 
devido ao seu tamanho, geralmente é anexado como um apêndice. 


3.2.10 Planejar as aquisições do projeto 


Aquisição é o termo atribuído ao processo de compra de bens ou servi- 
ços. A decisão de comprar ou não um produto ou serviço para o projeto 
é o primeiro passo a ser executado no gerenciamento de aquisições. 
Normalmente, o gerente de projetos escolhe adquirir aquilo que está fora 
do alcance da equipe interna do projeto para que as entregas previstas 
na WBS sejam cumpridas. Nessa conta inclui-se desde o conhecimento 
técnico até a disponibilidade para execução no momento adequado do 
projeto. 


As aquisições podem ser feitas por um departamento especializado em 
compras (gerenciamento de aquisições centralizado) ou pela própria 
equipe do projeto (gerenciamento de aquisições descentralizado). 


O planejamento das aquisições são as decisões de compra do projeto, com 
a devida especificação do que será utilizado para fazer essas aquisições e 
a identificação dos fornecedores em potencial que atendem às demandas 
existentes. Em outras palavras, o planejamento do gerenciamento de aqui- 
sições consiste em dizer o que será adquirido e como será adquirido. 
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É importante salientar que as principais funções envolvidas no processo 
de aquisição são: 


Definição das estratégias de aquisição, 
Lista de propostas aprovada, 

Pesquisa pré-licitação, 

Seleção do licitante, 

Solicitação de cotação, 103 
Avaliação da proposta, 

Pedido de compra, 

Expedição, monitoramento e inspeção, 

9. Envio e armazenamento, 

10. Montagem e instalação, 

11. Pagamento e arquivamento de documentação, 

12. Encerramento dos contratos ao final dos mesmos. 


Go E (ON Om RO 


3.2.11 Planejar a equipe do projeto 


O planejamento da equipe do projeto engloba os processos necessários 
à obtenção de profissionais internos ou externos à organização executora 
a fim de cumprir o escopo do projeto. 


Para isso se deve inicialmente planejar os recursos humanos necessários, 
ou seja, determinar a quantidade e o tipo de profissional necessário para 
a execução das várias atividades do projeto. Deve-se, também, fazer o 
recrutamento que é a busca interna e externa à organização de recursos 
que preencham os requisitos dos cargos. Então, faz-se a seleção que é 
a escolha entre possíveis profissionais para posteriormente fazer-se a 
contratação quando o recurso for externo à organização, ou a alocação 
do recurso quando for interno. Se for necessário faz-se a capacitação da 
equipe selecionada, oferecendo o conhecimento específico ao profissio- 
nal para que possa desempenhar suas tarefas da melhor maneira possí- 
vel. Por fim deve ser pensado, também, como será feita a desmobilização 
após a conclusão do projeto. 


Como ferramenta principal utilizada para fazer o gerenciamento da equi- 
pe do projeto utiliza-se a Matriz de Responsabilidade. A matriz de res- 
ponsabilidade liga o organograma do projeto ou da organização respon- 
sável pelo projeto a WBS, para garantir que todos os componentes dos 
pacotes de trabalho sejam designados a alguma pessoa do organograma. 
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A Matriz de Responsabilidade é amplamente adotada no gerenciamento 
de projetos para planejamento de recursos humanos. Uma vez que a 
equipe do projeto é temporária, a matriz é usada para a atribuição de 
responsabilidades aos membros da equipe do projeto. 


Existem dois tipos básicos para representação de uma Matriz de Respon- 
sabilidade. O primeiro é o tipo narrativo que apresenta uma descrição 
detalhada das responsabilidades, autoridade, competências, relações 
de trabalho, interações, duplicação e sobreposição de funções, assim 
como das qualificações necessárias. Esse primeiro tipo também pode 
ser apresentado como uma descrição de cargos e competências, que 
normalmente é um documento sob a responsabilidade da área de gestão 
de pessoas das organizações. O segundo tipo é uma matriz que associa 
as atividades do projeto com os responsáveis pelo desenvolvimento das 
atividades. 


3.2.12 Planejar as comunicações do projeto 


O processo de comunicação é a arte de tornar as informações dispo- 
níveis e inteligíveis para as pessoas.Para vários autores o processo de 
comunicação é um fator que pode garantir o sucesso ou o insucesso de 
um projeto, na medida em que a atividade de projetos é marcada pela 
interação de vários atores da organização e fora dela. O processo de co- 
municação é a base para a sobrevivência, o crescimento e a continuidade 
das organizações. Somente por meio de processo de comunicação eficaz 
é possível que as atividades distribuídas entre os vários colaboradores 
que integram uma organização atinjam os objetivos planejados (CARVA- 
LHO E MIRANDOLA, 2007)'º. 


O processo de comunicação permite que haja um entendimento mútuo 
e compartilhado entre os integrantes do projeto, sendo que a comuni- 
cação permanece como uma competência crítica para o gerenciamento 
de projetos e a competência do gerente de projeto em codificar e deco- 
dificar como a comunicação impacta na satisfação da equipe bem como 
em sua produtividade. Portanto, quanto melhor a capacidade do gerente 
do projeto em comunicar metas, objetivos e informações relevantes para 
todas as partes interessadas, maiores as chances de satisfação da equipe 
do projeto e aumento dos níveis de produtividade. 


De acordo com o Guia PMBOK (PMI, 2013), o gerenciamento da comu- 
nicação inclui os processos de (1) planejar o gerenciamento das comuni- 
cações, (2) gerenciar as comunicações, e (3) controlar as informações. O 
planejamento do gerenciamento das comunicações envolve o desenvol- 


13 CARVALHO, Marly Monteiro de. MIRANDOLA, Daniela. A comunicação em projetos de Tl: uma 
análise comparativa das equipes de sistemas e de negócios. Produção, v. 17, n. 2, p. 330-342, Maio/ 
Ago. 2007. 


vimento de uma abordagem adequada e um plano de comunicação com 
base nas necessidades e requisitos das partes interessadas. O gerencia- 
mento da comunicação envolve a criação, distribuição, armazenamento 
e recuperação das informações do projeto. Finalmente, o controle das 
informações visa assegurar que as necessidades de informações das par- 
tes interessadas do projeto estejam sendo atendidas. 


Para facilitar o processo de elaboração do planejamento, as ações de co- 
municação nos projetos podem ser sintetizadas em um quadro contendo 
as informações: O que deve ser comunicado? Por que será comunicado? 
Como será comunicado? Quem irá comunicar? Quando será comuni- 
cado? Quanto custará a comunicação? Onde será feita a comunicação? 
Essas perguntas correspondem à ferramenta conhecida como 5W2H, 
muito utilizada em vários outros processos organizacionais. 


A figura 16 apresenta um modelo de plano de comunicação elaborado a 
partir dessa ferramenta. 


Oque | Porque | Como Quem Quan- | Onde será | Quanto 
deve ser será será irá do será feita a custará 
comuni- | comuni- | comuni- | comuni- | comuni- | comuni- 

cado? cado? cado? car? cado? cação 


Figura 16 - Modelo de Plano de comunicação utilizando a ferramenta 5W2H 


3.2.13 Elaboração do Plano do Projeto e o Plano de Gerenciamento 
do Projeto 


O plano do projeto é um documento que congrega todos os documentos 
de planejamento do projeto. 


Ele é composto pelos seguintes documentos: 


1) Project Charter com: 
a) nome do projeto, 
b) objetivo, 
) custo estimado, 
d) prazo estimado, 
) benefícios esperados — justificativa do projeto, 
f) gerente de projeto e equipe —- nome dos elementos do grupo com 
e-mail, 
g) outras informações relevantes, 
h) premissas e restrições; 
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2) Plano de Escopo do Projeto: 
a) Declaração de Escopo do Projeto, 
b) Estrutura Analítica (WBS), 
c) Plano de gerenciamento de escopo — como lidar com as mudanças; 


3) Análise dos Stakeholders: 
a) Listar principais interessados, 
b) Descrever a natureza do interesse, 
c) Identificar posição (favorável ou desfavorável); 


4) Plano de tempo: 
a) Lista das Atividades, 
b) Precedências, 
) Durações, 
d) Cronograma, 
) Rede com caminho crítico, 
f) Forma de lidar com as mudanças; 


5) Plano de Custos: 
a) Recursos previstos, 
b) Custos previstos, 
c) Orçamento, 
d) Forma de lidar com as mudanças; 


6) Plano de Qualidade; 


7) Plano de Riscos: 
a) Identificação dos Riscos, 
b) Estimativa de Impacto e Probabilidade, 
c) Plano de gerenciamento de riscos; 


8) Plano de Comunicações; 


9) Plano de Aquisições: 
a) Definir o que será feito e o que será comprado, 
b) Critérios de avaliação de compras, 
c) Plano de gerenciamento de contratos; 


10) Plano Integrado do Projeto. 


Esse conjunto de documentos será a base para iniciar os processos de 
execução de um projeto. 


Já o plano de gerenciamento do projeto define como o mesmo é exe- 
cutado, monitorado e controlado, e encerrado. O conteúdo do plano 
de gerenciamento do projeto varia dependendo da área de aplicação e 
complexidade do projeto. Ele é desenvolvido através de uma série de 
processos integrados até o encerramento do projeto. Esse processo re- 
sulta em um plano de gerenciamento do projeto que é progressivamente 
elaborado através de atualizações, e controlado e aprovado através do 
processo de “realizar o controle integrado de mudanças”. 


3.3 Processos de Execução de um Projeto 


O processo de execução consiste em realizar as atividades previstas no 
plano do projeto, com o objetivo de se alcançarem os resultados espe- 
rados. Nesta fase realizam-se, também, ajustes na execução de forma a 
manter os esforços dirigidos no sentido da consecução do objetivo, nas 
condições planejadas. Esta fase encerra um complexo conjunto de habi- 
lidades do gerente e dos executivos, um elevado espírito de cooperação, 
muita coordenação e competência da equipe. 


Segundo o PMI (2013) na fase de execução do projeto, os resultados po- 
derão requerer atualizações no planejamento e mudanças nas linhas de 
base. Isso pode incluir mudanças nas durações esperadas para as ativida- 
des, mudanças na produtividade e na disponibilidade dos recursos e ris- 
cos imprevistos. Essas variações podem afetar o plano de gerenciamento 
do projeto ou os documentos do projeto e exigir uma análise detalhada 
e o desenvolvimento de respostas apropriadas de gerenciamento de pro- 
jetos. Os resultados da análise podem acionar solicitações de mudanças 
que, se forem aprovadas, poderão modificar o plano de gerenciamento 
ou outros documentos do projeto e talvez exigir a definição de novas 
linhas de base. Uma grande parte do orçamento do projeto será gasta na 
execução dos processos do grupo de processos de execução. 


A figura 17 demonstra os processos de execução do projeto. 


Entradas Processo Saídas 


1 — Plano do Projeto E — Orientar e sai 
2 — Politicas erenciar o trabalho 


Organizacionais Ex ecução do in 


3 — Ações Corretivas Plano do 2 — Requisições de 


Pro. je to Mudanças 


Figura 17- Processos de Execução do Projeto 
Fonte: Pmbok, 2013 


3.3.1 Orientar e gerenciar o trabalho realizado 


Orientar e gerenciar o trabalho realizado é o processo de liderar e reali- 
zar o trabalho definido no plano de gerenciamento do projeto e a imple- 
mentação das mudanças aprovadas para atingir os objetivos do projeto. 


Segundo o PMI (2013) no processo de orientar e gerenciar o trabalho 
realizado, os dados de desempenho do trabalho são coletados, aciona- 
dos e comunicados de forma apropriada. Os dados de desempenho do 
trabalho incluem informações sobre o progresso de finalização das en- 
tregas e outros detalhes relevantes sobre o desempenho do projeto. Os 
dados sobre o desempenho do trabalho, também, serão utilizados como 
entrada no grupo de processos de monitoramento e controle. 
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3.3.2 Requisições de mudanças 


Uma requisição de mudança é uma proposta formal para modificar qual- 
quer documento, entrega, ou linha de base. Uma requisição de mudança 
aprovada substituirá o respectivo documento, entrega ou linha de base, 
e pode resultar em uma atualização de outras partes do plano de geren- 
ciamento do projeto. Quando são encontrados problemas enquanto o 
trabalho do projeto está sendo executado, são apresentadas solicitações 
de mudança que podem modificar políticas ou procedimentos, escopo, 
custo ou orçamento, cronograma e qualidade do projeto. 


3.4 Processos de Monitoramento e Controle 
de um Projeto 


O desempenho do projeto deve ser monitorado e medido regularmente 
para identificar as variações em relação ao planejado. À medida que são 
identificados desvios significativos no projeto, ou seja, aqueles que podem 
colocar em risco os objetivos do projeto, devem-se realizar os ajustes ne- 
cessários e as respectivas atualizações nos processos de planejamento. 


Podem-se associar ao processo de monitoramento e controle de um pro- 
jeto dois processos, a saber: relato do desempenho e controle integrado 
de mudanças. 

A figura 18 apresenta os dois processos de monitoramento e controle de 


um projeto. 


Processo 1 Processo 2 


Relato do Controle 


Integrado de 
Desempenho Mudanças 


Figura 18 - Processos de monitoramento e controle de um projeto 
Fonte: PMI, 2013 


O relato do desempenho constitui-se da coleta e disseminação das in- 
formações de desempenho do projeto. Nesse caso são dados de entrada 
para se desenvolver esse processo, o plano do projeto e os resultados das 
atividades desenvolvidas na execução do projeto. A partir da comparação 
dos resultados das atividades com o plano do projeto faz-se o relatório 
de desempenho e as solicitações ou requisições de mudanças. Lembre- 
-se que as requisições de mudanças devem ser analisadas para avaliar o 
seu impacto no escopo, no tempo, no custo e na qualidade do projeto. 


O controle integrado de mudanças é o processo de controle das altera- 
ções realizadas no planejamento inicial, ao longo da execução do proje- 
to. Segundo o PMI (2013) é o processo de revisar todas as solicitações de 
mudança, aprovar as mudanças e gerenciar as mudanças nas entregas, 
ativos de processos organizacionais, documentos do projeto e no plano 
de gerenciamento do projeto, e comunicar a decisão sobre os mesmos. 
Ainda segundo o PMI (2013) esse processo de controle integrado de mu- 
danças é conduzido do início ao término do projeto, e é de responsabili- 
dade final do gerente de projetos. O plano de gerenciamento do projeto, 
a especificação do escopo do projeto e outras entregas são mantidas 
através do gerenciamento cuidadoso e contínuo das mudanças, através 
da rejeição ou aprovação das mesmas, assegurando, assim, que somente 
as mudanças aprovadas sejam incorporadas à linha de base revisada. É 
importante salientar que todas as requisições de mudança documenta- 
das precisam ser aprovadas ou rejeitadas por uma pessoa responsável, 
geralmente o patrocinador ou o gerente do projeto. A pessoa responsá- 
vel será identificada no plano de gerenciamento do projeto ou por proce- 
dimentos organizacionais. 


3.5 Processos de Encerramento/ 
Finalização de um Projeto 


Ao final de um projeto, as pessoas apresentam uma tendência em relaxar, 
passar para outras atividades e menosprezar as prioridades de inspeção 
final relacionadas ao projeto. Mas isso não deve acontecer. A avaliação 
final e os relatórios de conclusão do projeto são valiosas contribuições 
tanto para o projeto em si como para o sucesso de iniciativas futuras. 


Os processos de encerramento mostram-se necessários para evitar que, 
mesmo após o término do projeto, algumas pendências relacionadas ao 
mesmo comprometam as atividades da organização. 


Segundo o PMI (2013), e demonstrado na Figura 19, os processos de 
encerramento são todos aqueles que são executados para finalizar todas 
as atividades de todos os grupos de processos, visando encerrar formal- 
mente o projeto. São diretrizes ou requisitos de encerramento do proje- 
to: lições aprendidas, auditorias finais do projeto, avaliação do projeto, 
validação de produto e critérios de aceitação. 


Ainda segundo o PMI (2013) este grupo de processos também formali- 
za o encerramento prematuro do projeto. Os projetos encerrados pre- 
maturamente podem incluir, por exemplo, projetos abortados, projetos 
cancelados e projetos em situação crítica. Em casos específicos, quando 
alguns contratos não podem ser formalmente encerrados (ex.: reclama- 
ções, cláusulas de encerramento, etc.) ou algumas atividades devam ser 
transferidas para outras unidades organizacionais, procedimentos espe- 
cíficos de entrega devem ser providenciados e finalizados. 
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Processos de Monitoramento e Controle 


Processos de 
Planejamento 


Iniciar o Finalizar 0 
projeto projeto 
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Processos de 
Iniciação 


é 0 Figura 19 - Processos de Gerenciamento de um projeto - Processos de Encerramento 
Fonte: Elaboração própria a partir do Pmbok, 2013. 


As principais ações a serem desenvolvidas para encerrar um projeto en- 
volvem, segundo Gido, Clements e Baker (2018): 


* receber e fazer pagamentos finais; 

* reconhecer e avaliar o pessoal; 

* conduzir uma avaliação pós-projeto; 

* documentar as lições aprendidas; 

* organizar e arquivar os documentos do projeto. 


Já o PMI (2013) define como processos de encerramento de um projeto: 


* obter a aceitação pelo cliente ou patrocinador para encerrar formal- 
mente o projeto ou fase; 


* fazer a revisão pós-projeto ou de final de fase; 
* registrar os impactos de adequação de qualquer processo; 
* documentar as lições aprendidas; 


* aplicar as atualizações apropriadas aos ativos de processos 
organizacionais; 


* arquivar todos os documentos relevantes do projeto no sistema de 
informações de gerenciamento de projetos (SIGP) para serem usados 
como dados históricos; 


* encerrar todas as atividades de aquisições, assegurando a rescisão de 
todos os acordos relevantes; 


* executar a avaliação dos membros da equipe e liberar os recursos do 
projeto (desmobilização). 


3.5.1 Obter a aceitação pelo cliente ou patrocinador para encerrar 
formalmente o projeto ou fase 


A aceitação pelo cliente deverá acontecer após a realização de todas as 
atividades previstas para entrega do escopo do mesmo. Já definidos na 
fase de planejamento, os critérios de aceitação deverão ser revistos nes- 
se momento para garantir que o escopo definido tenha sido desenvolvi- 
do por completo e que não ficaram pendências para serem cumpridas. 
A obtenção do aceite do cliente deverá ser formalizada para garantir que 
o mesmo está de acordo com o que lhe foi entregue. Isso pode ser feito 
por um documento, em que o cliente declara que o projeto foi entregue 
dentro do escopo que foi definido na fase de iniciação e de planejamento. 
Se mudanças de escopo foram feitas e aprovadas pelo cliente, deverão 
constar do documento final de aceitação que será assinado pelo cliente. 


3.5.2 Revisão pós-projeto ou de final de fase 


A avaliação pós-projeto deverá ser conduzida com o objetivo de rever e 
avaliar o desempenho do projeto e identificar o que pode ser feito para 
melhorá-lo em projetos futuros. Essa atividade pode ser realizada por meio 
de reuniões individuais ou com todos os membros da equipe de projetos. 


As reuniões individuais têm por finalidade a emissão das impressões pes- 
soais sobre a realização do projeto e o que pode ser feito para melhorar 
os projetos futuros. Tais reuniões permitem que as pessoas falem aber- 
tamente, sem as restrições ou constrangimentos de reuniões em grupo. 
É importante que o gestor do projeto mencione que as informações ge- 
radas nessas reuniões individuais serão tratadas de forma sigilosa e que 
não serão divulgadas sem a prévia autorização das pessoas. 


As reuniões com todos os membros da equipe de projetos têm por obje- 
tivo conduzir uma discussão sobre o que aconteceu durante a execução 
do projeto e solicitar recomendações específicas para projetos futuros. 
Vale ressaltar a importância de se discutir as lições aprendidas durante a 
execução do projeto. 


Compõe, ainda, atividade dessa fase de pós-projeto a realização do co- 
missionamento!?. Esse comissionamento nada mais é do que a transi- 
ção da fase final do projeto para a fase inicial de funcionamento das 


14 Comissionamento: antes de uma planta ser colocada em operação, ela deve ser verificada e 
testada. Este processo é chamado de comissionamento e envolve o contratante e o operador da 
instalação concluída. Um planejamento cuidadoso é necessário, especialmente se a planta for parte 
de uma instalação existente que deve permanecer totalmente operacional com o mínimo de inter- 
rupção durante o processo de comissionamento. A integração com os sistemas existentes (espe- 
cialmente quando os computadores estão envolvidos) deve ser contínua, e isso pode exigir que os 
sistemas existentes e novos sejam operados simultaneamente até que todos os problemas identifi- 
cados sejam resolvidos. 
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atividades continuadas associadas ao novo processo ou à produção do 
novo produto resultante do projeto desenvolvido. Essa fase aplica-se, 
principalmente, a projetos que envolvem trabalhos de construção ou 
instalação, durante a qual os testes de desempenho e operacionais es- 
pecificados são realizados com o objetivo de provar ao cliente que os 
produtos estão conforme especificado e em conformidade com os cri- 
térios de desempenho exigidos. Frequentemente, o comissionamento é 
realizado com o auxílio de operários do cliente e tem a vantagem de que, 
desta forma, as pessoas que irão operar a planta ou sistema aprenderão 
a operar os controles e fazer os ajustes necessários. Em projetos mais 
complexos, pode ser necessário executar programas especiais de treina- 
mento e capacitação para que os funcionários e operativos dos clientes 
se familiarizem com as novidades implementadas pelo projeto em ques- 
tão. Inclui-se nesse processo a organização de todos os documentos as- 
sociados ao projeto como manuais de operação, manuais de lubrificação 
e manutenção, dentre outros. 


3.5.3 Registrar os impactos de adequação de qualquer processo 


A maioria das organizações hoje em dia exige que o gerente de projeto 
produza um relatório de encerramento no final do projeto. Isso pode 
ser demorado e burocrático. Em muitos casos os gerentes de projetos 
já foram designados para conduzir outros projetos e se debruçar para 
elaborar um relatório de encerramento do projeto pode parecer uma 
atividade tediosa e que irá desperdiçar o tempo do gestor. Mas, se o 
gestor do projeto for organizado e desde o início do projeto tiver feito 
um diário razoavelmente detalhado, a tarefa de produzir um relatório de 
encerramento não é tão onerosa quanto possa parecer. As informações 
fornecidas no relatório devem cobrir não apenas o que deu errado e por 
que, mas também os sucessos e conquistas na superação de qualquer 
problema particularmente interessante. 


Usando o relatório de encerramento como base, a tarefa final do gerente 
de projeto é realizar uma revisão pós-projeto (ou uma revisão pós-imple- 
mentação), que deve abranger um breve histórico do projeto e uma aná- 
lise dos sucessos e falhas junto com uma descrição de como essas falhas 
foram tratadas. A revisão também discutirá o desempenho da equipe do 
projeto e as contribuições (positivas e negativas) das outras partes inte- 
ressadas. Todas essas informações podem, então, ser examinadas por 
futuros gerentes de projeto e empregadas em projetos semelhantes, de 
modo que possam ser informados das dificuldades e problemas encon- 
trados e garantir (na medida do possível) que os mesmos problemas não 
surjam. 


Abaixo são listadas alguns tópicos que devem ser incluídos em um rela- 
tório de encerramento, segundo Lester (2014): 


* Grau em que os objetivos originais foram alcançados; 
* Grau de conformidade com o brief do projeto (business case); 


* Grau em que os KPIs (Key Performance Indicator)'* originais foram 
alcançados; 

* Nível de satisfação expresso pelo cliente ou patrocinador; 

* Comparação entre o custo original (orçado) e o custo final real; 

e Razões para estouros de custo (se houver); 

* Principais mudanças incorporadas devido a: 
(a) requisitos aprovados do cliente, 
(b) modificações internas causadas por erros ou omissões, 
(c) outras razões possíveis (estatutárias, ambientais, legais, de saúde 
e segurança, etc.); 

* Comparação entre o tempo do projeto original e o tempo total real 
gasto; 

* Razões para atrasos ou atrasos no tempo; 

* Grandes atrasos e as causas desses atrasos. 


3.5.4 Documentar as lições aprendidas 


As lições aprendidas são todo o conjunto de conhecimento adquirido 
durante um projeto que mostra como os eventos do projeto foram abor- 
dados ou devem ser abordados, com o objetivo de melhorar o desem- 
penho futuro. 


Aprender com os erros anteriores é um processo natural desenvolvido 
desde a infância. Ainda mais benéfico e certamente de alcance mais am- 
plo é aprender com os erros de outras pessoas. Por exemplo, quando 
um novo gerente de projeto descobre que tem que lidar com um forne- 
cedor, que foi descrito como “difícil” em um relatório de encerramento 
anterior, ele ou ela deve entrar em contato com o gerente de projeto 
anterior e descobrir as melhores formas de “lidar” com esse fornecedor. 
Por esta razão, a revisão de encerramento, juntamente com o relatório de 
encerramento mais formal, deve ser indexado de forma adequada e ar- 
quivado em cópia impressa ou formato eletrônico para fácil recuperação. 


Incluem-se como lições aprendidas as causas das variações, O raciocí- 
nio por trás da ação corretiva escolhida e outros tipos de lições apren- 
didas com todos os processos de gestão do projeto documentados para 
inclusão no banco de dados históricos do projeto e da organização 
executora. 


15 KPI - Key Performance Indicator - Um indicador-chave de desempenho (KPI) é um critério prin- 
cipal contra o qual uma parte específica do projeto pode ser medida. Um KPI pode ser um marco 
que deve ser cumprido, um estágio pré-determinado de design, entrega, instalação, produção, teste, 
montagem e comissionamento, uma data de pagamento (entrada ou saída) ou qualquer outra fase 
importante em um projeto. 
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3.5.5 Aplicar as atualizações apropriadas aos ativos de 
processos organizacionais 


Segundo o PMI (2013) os ativos de processos organizacionais que são 
atualizados como resultado do processo encerrar o projeto inclui os ar- 
quivos do projeto, que são toda documentação resultante das atividades 
do projeto (plano de gerenciamento do projeto, escopo, custo, crono- 
grama e calendários do projeto); registros dos riscos e outros registros 
(documentação de gerenciamento de mudança, ações planejadas de res- 
posta aos riscos e impacto de risco); os documentos de encerramento 
do projeto ou fase, que consistem em documentação formal indicando 
a conclusão do projeto ou fase e a transferência das entregas do projeto 
concluído ou fase concluída para outros, tais como um grupo de ope- 
rações ou para a próxima fase; e as Informações históricas, que são as 
informações e as lições aprendidas que deverão ser transferidas para a 
base de conhecimento de lições aprendidas para uso em projetos futu- 
ros. Incluem-se as informações a respeito de problemas e riscos, assim 
como técnicas que funcionaram bem e que podem ser aplicadas em pro- 
jetos futuros. 


3.5.6 Arquivar todos os documentos relevantes do projeto no 
sistema de informações de gerenciamento de projetos (SIGP) 
para serem usados como dados históricos 


Os sistemas de informações de gerenciamento de projetos são siste- 
mas que permitem coletar, recuperar, processar, armazenar e distribuir 
informações sobre os projetos desenvolvidos pela organização com a 
finalidade de facilitar o planejamento, o controle, a coordenação, a aná- 
lise e o processo decisório nas organizações. Se o gestor do projeto ou 
a sua equipe trabalharem de forma organizada, todos os documentos 
relevantes do projeto já estarão armazenados no sistema de informações 
de gerenciamento de projetos da empresa. Nesta etapa basta verificar 
se todos eles foram armazenados de forma correta e que permita a sua 
recuperação, quando for necessário. 


3.5.7 Encerrar todas as atividades de aquisições, assegurando 
a rescisão de todos os acordos relevantes 


Em relação ao encerramento de todas as atividades de aquisições, as- 
segurando a rescisão de todos os acordos relevantes, é importante sa- 
lientar que todos os contratos (e subcontratos) devem ser devidamente 
encerrados e (se possível) todas as reivindicações e encargos atrasados 
(incluindo indenização por danos) acordados e liquidados. 


Devem ser tomadas providências para descartar e/ou armazenar os itens 
não utilizados ou materiais excedentes. Eles podem ser vendidos ao 
cliente com desconto ou armazenados para uso em outro projeto. Todos 
os rendimentos auferidos com a venda desses itens deverão ser credita- 
dos ao projeto. 


3.5.8 Executar a avaliação dos membros da equipe e liberar 
os recursos do projeto (desmobilização) 


A equipe agora terá que ser dissolvida. Esse pode ser um processo difícil 
para os indivíduos. Em muitos casos é o estágio de “luto”, segundo Tuck- 
man (1977)!. Em grandes projetos que exigiam que a equipe trabalhasse 
junta por muitos meses ou anos, o fechamento pode ser um anticlímax 
terrível e o aspecto humano deve ser tratado diplomaticamente e com 
simpatia. Além da desmobilização das pessoas, deverá ser feita a des- 
mobilização de todos os outros recursos utilizados no projeto, como 
máquinas, equipamentos e materiais que sobraram. 


ATIVIDADES 


Objetivo: Desenvolver, individualmente, um trabalho prático cujo 
objetivo é elaborar um plano de projeto, utilizando os conceitos e 
técnicas desenvolvidas no capítulo 3. 


Temas Possíveis: 


1. Projetos socioambientais: sistemas de coleta seletiva de lixo, 
aproveitamento de água de chuva, etc.; 


2. Desenvolvimento de novos produtos, processos ou serviços; 
Se Projetos de Construção e Engenharia; 


4. Projetos de tecnologia de informação: desenvolvimento ou im- 
plantação de sistemas, etc.; 


5. Evento Social. 


Prazo para entrega da atividade 
A entrega final do trabalho deverá ser feita no dia (A COMBINAR), 
na plataforma do curso até às (HORÁRIO A COMBINAR). 


O que deve ser entregue 


1. Project Charter com: 
a) nome do projeto, 
b) objetivo, 
c) custo estimado, 
) prazo estimado, 
e) benefícios esperados — justificativa do projeto, 
f) gerente de projeto e equipe — nome dos elementos do gru- 
po com e-mail, 


16 Para saber mais sobre os estágios de desenvolvimento de equipes veja artigo escrito por Tuckman 
intitulado “Stages of Small-Group Development Revisited” que foi publicado na Group & Organiza- 
tion Studies, December 1977, 2(4),419-427. 
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g) outras informações relevantes, 
h) premissas e restrições; 


2. Plano de Escopo do Projeto: 
a) Declaração de Escopo do Projeto, 
b) Estrutura Analítica (WBS), 
c) Plano de gerenciamento de escopo — como lidar com as 
mudanças; 
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3. Análise dos Stakeholders : 
a) Listar principais interessados, 
b) Descrever a natureza do interesse, 
c) Identificar posição (favorável ou desfavorável); 


4. Plano de tempo: 
16 a) Lista das Atividades, 
b) Precedências, 
c) Durações, 
Cronograma, 
Rede com caminho crítico, 
f) Forma de lidar com as mudanças; 


5. Plano de Custos: 
a) Recursos previstos, 
b) Custos previstos, 
c) Orçamento, 
d) Forma de lidar com as mudanças; 


6. Plano de Qualidade; 


7. Plano de Riscos: 
a) Identificação dos Riscos, 
b) Estimativa de Impacto e Probabilidade, 
c) Plano de gerenciamento de riscos; 


8. Plano de Comunicações; 


9. Plano de Aquisições: 
a) Definir o que será feito e o que será comprado, 
b) Critérios de avaliação de compras, 
c) Plano de gerenciamento de contratos; 


10. Plano Integrado do Projeto. 


GLOSSÁRIO 


Sistema de informações de gerenciamento de projetos (SIGP) - São sis- 
temas que permitem coletar, recuperar, processar, armazenar e distribuir 
informações sobre os projetos desenvolvidos pela organização com a fi- 
nalidade de facilitar o planejamento, o controle, a coordenação, a análise 
e o processo decisório nas organizações. 


Key Performance Indicator - KPI - Um indicador-chave de desempenho 
(KPI) é um critério definido para medir alguns aspectos específicos do 
projeto. 


Project chart - Um documento que formalmente autoriza a existência 
de um projeto e dá ao gerente do projeto a autoridade necessária para 
aplicar recursos organizacionais às atividades do projeto. 


Work Breakdown Structure - WBS - É um agrupamento dos componen- 
tes do projeto, orientados para o resultado principal, que organiza e de- 
fine o escopo total do projeto. 


Plano Integrado do Projeto - Inclui as ações necessárias para identificar, 
definir, combinar, unificar e coordenar os vários processos e atividades 
dentro dos grupos de processos de gerenciamento. 


RACI - Um tipo comum de matriz de alocação de responsabilidades que 
indica os papéis Responsável pela execução, responsável pela Aprova- 
ção, deve ser Consultado e deve ser Informado para definir o tipo de 
envolvimento das partes interessadas nas atividades do projeto. 


REFERÊNCIAS BIBLIOGRÁFICAS DO CAPÍTULO 3 


CARVALHO, Marly Monteiro de. MIRANDOLA, Daniela. A comunicação 
em projetos de TI: uma análise comparativa das equipes de sistemas e de 
negócios. Produção, v. 17, n. 2, p. 330-342, Maio/Ago. 2007. 


CLEMENTS, James P. GIDO, Jack. Gestão de projetos. 2. ed. São Paulo: 
Cengage, 2013. 


GOLANY, Boaz. SHTUB, Avraham. Handbook of Industrial Engineering: 
Technology and Operations Management, Third Edition. Edited by Ga- 
vriel Salvendy, 2001. 


LESTER, Albert. Project Management, Planning, and Control Managing 
Engineering, Construction, and Manufacturing Projects to PMI, APM, 
and BSI Standards. Sixth Edition. Oxford, Elsevier, 2014, 548 p. 


L 


CAPITULO 3 


117 


L 


CAPITULO 3 


118 


PMI. Project Management Institute. Um Guia do Conjunto de Conhe- 
cimentos em Gerenciamento de Projetos: Guia PmbokO. 3. ed. EUA: 
Book Editor, 2015. 


VALERIANO, Dalton L. Gerência em Projetos: Pesquisa, Desenvolvi- 
mento e Engenharia. São Paulo: Makron Books, 1998. 


VALLE, A. B. et al. Fundamentos do gerenciamento de projetos. 2. ed. 
Rio de Janeiro: FGV, 2010. 


CAPÍTULO IV 


AS ESTRUTURAS ORGANIZACIONAIS 
E A SUA INFLUÊNCIA NA 
ATIVIDADE DE PROJETOS 


Prof. Ricardo Thielmann 


Objetivos Específicos 


* Explicar os três tipos principais de estruturas organizacionais de ges- 
tão de projetos; 


* Discutir as vantagens e desvantagens de cada um dos três tipos de 
estrutura organizacional de gestão de projetos; 


* Descrever o papel de um escritório de gerenciamento de projetos em 
uma estrutura organizacional de projetos. 


Introdução 


A estrutura organizacional frequentemente restringe a disponibilidade 
ou as condições sob as quais os recursos se tornam disponíveis para o 
projeto. 


Na organização clássica, com estrutura funcional, em que cada funcio- 
nário tem um superior bem definido, os membros da equipe são agrupa- 
dos por especialidade. A estrutura organizacional funcional é tipicamente 
usada em empresas que vendem e fabricam principalmente produtos-pa- 
drão e raramente conduzem projetos externos. As estruturas funcionais 
são caracterizadas pela distribuição das pessoas em grupos que realizam 
a mesma função, como engenharia ou fabricação, ou têm experiências 
ou habilidades idênticas, como engenharia eletrônica ou testes. Cada 
grupo funcional, ou área, concentra-se em realizar as próprias ativida- 
des dentro da missão comercial da empresa. O foco está na excelência 
técnica e na competitividade de preços dos produtos da empresa, assim 
como na importância da contribuição da experiência de cada área funcio- 
nal aos produtos da empresa. 
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Portanto, apesar de grande parte das organizações apresentarem uma 
estrutura funcional clássica, esse tipo não é a melhor estrutura para con- 
duzir projetos, por suas características específicas. 


Além disso, a estrutura organizacional interna, que será definida para 
conduzir projetos, depende de alguns fatores como o caráter do projeto, 
o tamanho e a complexidade do projeto, a tecnologia, os processos e 
os procedimentos envolvidos e a maturidade e habilidades da equipe 
de projetos. Pelas suas características únicas, apresentadas pelas ativida- 
des de projetos, normalmente, uma atividade de projeto é uma estrutura 
temporária alojada dentro de uma estrutura funcional. 


Então, para gerenciar um projeto, uma organização deve estabelecer uma 
estrutura organizacional de projeto, que pode fornecer os recursos para 
o projeto e atendê-lo durante seu ciclo de vida. Segundo Lester (2014) 
existem três tipos principais de organizações de projeto: 


a) Funcional, 
b) Matricial, 
c) Projetizada. 


4.1 Estrutura Funcional 


A estrutura funcional consiste em departamentos especializados ou fun- 
cionais, cada um com seu próprio gerente departamental responsável 
pelas atividades desenvolvidas por esse departamento. Esse tipo de es- 
trutura organizacional é ideal para operações de rotina em que há pouca 
variação do produto final. As organizações funcionais geralmente são 
encontradas onde os itens produzidos são padronizados. Cada depar- 
tamento é especialista em sua função e a inter-relação entre eles está 
bem estabelecida. Nesse sentido, uma organização funcional não é uma 
organização do tipo projeto e só é incluída porque, quando projetos pe- 
quenos, individuais e pontuais precisam ser realizados, eles podem ser 
atribuídos a um departamento específico para gerenciá-los. Para qual- 
quer outro tipo de projeto, será necessário estabelecer um dos outros 
dois tipos de organização. 


As vantagens essenciais de uma estrutura funcional são a simplicidade, 
a lógica e a independência. O objetivo principal é a busca da excelência 
funcional. Outra vantagem é a ausência de duplicação de atividades. Po- 
dem favorecer a eficácia, o controle, a boa comunicação e a coordenação 
de esforço, porém nem sempre são economicamente eficientes no uso 
de serviços e recursos, porque exigem instalações exclusivas. É caracte- 
rizada por uma estrutura hierárquica de poder, “cadeia de comando”, e 
pela especialização em “silos” funcionais. 


A figura 1 apresenta as vantagens e desvantagens de uma estrutura 
funcional. 


Competência Técnica 


* Desenvolvimento e manutenção de 
competência técnica em áreas espe- 
cializadas; 


* Sinergia entre especialistas. 


* Percepção limitada: falta de visão 
geral; 


* Dificuldade de integrar diferentes 
especialidades: possibilidade de 


conflitos entre os especialistas; 


* Dificuldade na criação de motivação 
para o projeto; 


e Falta de abertura no ambiente; 


* Risco de negligência de aspectos não 
relacionados com a especialidade. 


Objetivos 


e Concentração nos objetivos da 
função; 


* Foco em objetivos de desenvolvi- 
mento de longo prazo; 


e Facilidade de reconciliação dos ob- 
jetivos internos. 


* Conflitos de prioridades com outras 
atividades funcionais; 


* Dificuldade em balancear de forma 
eficaz as variáveis qualidade-tempo- 


-custo; 


* Ninguém é o responsável exclusivo 
pelos objetivos do projeto; 


* Subordinaçãodogerencialaotécnico. 


Permanência e estabilidades 


e Relações horizontais são claras; 


e Clara definição de funções e res- 
ponsabilidades; 


e Eficiência melhorada pela 
padronização; 


* Planos de carreira bem definidos; 


e Possibilidades de aprendizado 
organizacional. 


* Dificuldade em adaptar: resistên- 
cia a mudanças; 


e* Dificuldade na circulação interna 
de informações; 


e | Tomada de decisão lenta. 


Controle 


* Maior facilidade de controle de 
qualidade e desempenho; 


* Flexibilidade e economia do uso do 
trabalho. 


* Avariáveltempo émenos controlada; 


* Comprometimento limitado com o 
exterior; 


* Falta de visibilidade para o cliente; 


* Desenvolvimento limitado das capa- 
cidades gerenciais entre as pessoas. 


Figura 1 - Vantagens e Desvantagens da Estrutura Funcional 


Fonte: Elaboração própria, 2020 
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4.2 Estrutura Matricial 


A estrutura organizacional matricial é, provavelmente, o tipo mais co- 
mum de organização de projeto, uma vez que utiliza uma organização 
funcional existente para fornecer os recursos humanos sem interromper 
a operação do dia a dia da organização. 


O pessoal alocado em um projeto específico é responsável, perante um 
gerente de projeto, por atender aos quatro critérios básicos do projeto: 
escopo, tempo, custo e qualidade. 


A estrutura matricial fornece foco no projeto e no cliente, pois a estrutura 
é orientada para projetos, mas mantém a especialização da estrutura fun- 
cional. O gerente de projetos é responsável pelos resultados do projeto 
e o gerente funcional é responsável por fornecer os recursos necessários 
para alcançar os resultados dos projetos. A organização matricial pro- 
porciona a utilização eficaz dos recursos da empresa, pois os membros 
desta equipe de projeto ainda estão trabalhando em suas mesas, em seus 
departamentos, mas estão reservando parte de seu tempo para o proje- 
to. Quando o projeto não garante uma contribuição em tempo integral, 
apenas as horas realmente gastas no projeto serão alocadas a ele. As 
áreas funcionais contêm as equipes técnicas e fornecem um conjunto de 
conhecimentos para apoiar os projetos em andamento. 


Segundo Lester (2014) as principais vantagens de uma organização 
matricial são: 


a) os recursos são empregados de forma eficiente, uma vez que a equi- 
pe pode mudar para projetos diferentes sem ficar presa em qualquer 


um deles; 


b) a experiência acumulada pelo departamento é utilizada e as mais 
recentes técnicas de ponta são imediatamente incorporadas; 


c) a aquisição de instalações especiais não precisam ser fornecidas e os 
movimentos da equipe são evitados; 


d) as perspectivas de carreira dos membros da equipe são mantidas 
intactas; 


e) aorganização pode responder rapidamente às mudanças de escopo; e 


f) o gerente de projeto não precisa se preocupar com problemas de 
pessoal. 


Ainda segundo Lester (2014) as principais desvantagens são: 


a) pode haver um conflito de prioridades entre diferentes projetos; 


b) pode haver divisão de lealdade entre o gerente de projeto e o gerente 
do departamento devido aos requisitos de relatórios duplos; 


c) as comunicações entre os membros da equipe podem ser afetadas se 
as localizações dos departamentos estiverem distantes; e 


d) a gerência executiva pode ter que despender mais tempo para ga- 
rantir um equilíbrio justo de poder entre o gerente de projeto e o 
gerente de departamento. 


4.3 Estrutura Projetizada 


Do ponto de vista de um gerente de projeto, este é o tipo ideal de organi- 
zação de projeto, uma vez que, com tal configuração, ele tem controle to- 
tal sobre todos os aspectos do projeto. A equipe do projeto normalmente 
estará localizada em uma área, sob sua tutela e o controle dos recursos 
necessários para a execução do projeto estará sob sua responsabilidade. 


Nesse tipo de estrutura o processo de comunicação se torna mais eficaz 
pois as linhas de comunicação são curtas e a interação das disciplinas re- 
duz o risco de erros e mal-entendidos. Na estrutura projetizada todas as 
funções técnicas e de planejamento fazem parte da equipe, assim como 
o controle de custos do projeto e a equipe de contabilidade. 


Isso coloca uma carga de responsabilidade maior para o gerente de pro- 
jeto, que terá que delegar grande parte da gestão do dia a dia a coorde- 
nadores de projetos especiais, cuja função principal é garantir um bom 
fluxo de comunicação e o recebimento de relatórios e informações de 
feedback de fontes internas e externas. Isso conduz à necessidade de 
aumento do número de pessoas responsáveis pela gestão do projeto. 


Na estrutura projetizada cada projeto opera como uma entidade própria 
de certa forma independente sendo que todos os recursos necessários 
para realizar cada projeto são atribuídos em tempo integral para traba- 
lhar no projeto. Isso quer dizer que cada projeto deve pagar todos os 
recursos alocados a eles. Esse tipo de estrutura torna os projetos inde- 
pendentes do restante da organização, dá ao gerente de projetos total 
autoridade sobre os recursos e facilita o desenvolvimento de equipes 


técnicas multidisciplinares. 


A figura 2, apresenta resumidamente as principais vantagens e desvanta- 
gens da estrutura projetizada. 
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Vantagens Desvantagens 


* Clara definição do responsável geral | * Duplicação de esforços e recursos; 

pelo projeto; 
* Limitado desenvolvimento e acu- 
* Bons sistemas de integração; mulação de conhecimentos; 


* Maior contato direto entre diferen- | * Instabilidade do emprego; 
tes disciplinas; 

* Pode tender a sacrificar a qualida- 

* Canais de comunicação claros como | de técnica para focar em variáveis 
cliente e outras partes interessadas; | de maior visibilidade como prazo e 

custo. 

* Prioridades claras; 


* Balanço eficiente entre prazo, cus- 
tos e qualidade; 


* Orientação ao cliente; 


* Orientação a resultados. 


Figura 2 - Vantagens e desvantagens da estrutura projetizada 
Fonte: Elaboração própria, 2020. 


A figura 3, apresenta um resumo das principais estruturas organizacio- 
nais e suas características. 


Figura 3 - Tipos de Estruturas de Projetos e suas características 
Fonte: PMI, 2013 


4.4 O Escritório de Gerenciamento de Projetos - EGP 


A adoção de práticas avançadas de gestão de projetos depende da exis- 
tência de um mínimo de infraestrutura de apoio aos gerentes e equipes 
de projeto, tais como padronização, recursos e sistemas de informação. 
A partir dessa constatação os escritórios de gerenciamento de projetos - 
EGP (Project Management Office - PMO) são um dos aspectos organiza- 
cionais que vêm recebendo muita atenção, pois existem comprovações 
de que ele simplifica e otimiza a gestão de projetos a baixo custo, os 
projetos são gerenciados de forma metódica e padronizada e diminuem 
o trabalho dos gerentes de projetos, pois os escritórios de gerenciamen- 
to de projetos padronizam as melhores práticas de gerenciamento de 
projetos (KERZNER, 2016). 


O escritório de gerenciamento de projetos é a estrutura organizacional 
estabelecida para facilitar as atividades da gestão de projetos e trazer me- 
lhorias ao próprio processo de gestão da organização por meio da gestão 
do portfólio e do alinhamento de projetos com a estratégia corporativa 
(CRAWFORD, 2002). O escritório de gerenciamento de projetos é sem- 
pre um centro de conhecimento em gerenciamento de projetos dentro 
da empresa, e é sempre utilizado como um recurso para apoiar e auxiliar 
os gerentes de projetos. Os escritórios de gerenciamento de projetos fo- 
ram criados para garantir o conhecimento e o uso dos melhores padrões 
de gerenciamento de projetos em todos os projetos. A fim de melhorar o 
sucesso geral do projeto em todos os projetos, os escritórios procuraram 
as melhores práticas e as usaram para introduzir os processos padrão de 
todo o projeto da empresa. 


A principal função do escritório de gerenciamento de projetos está em 
promover a ordem e padronização para a gestão eficiente dos projetos 
de uma organização, dando suporte à gestão de recursos necessários ao 
projeto e à implementação das estratégias organizacionais. Atualmente o 
escritório de projetos tem a responsabilidade de manter toda a proprie- 
dade intelectual relativa à gestão de projetos e de ativamente sustentar o 
planejamento estratégico da corporação. 


Apesar de estar em destaque atualmente, o escritório de gerenciamento 
de projetos não é um conceito novo. Na década de 60, do séc. XX, já 
era utilizado por empresas de grande porte para desenvolvimento de 
projetos de alta complexidade, principalmente nas áreas militar e aero- 
espacial. Em meados da década de 80 do mesmo século, os primeiros 
softwares de gestão de projetos aumentaram a necessidade de utilização 
de escritórios para gerenciamento de projetos, dando muita ênfase às 
melhores práticas associadas aos processos de gestão de projetos que 
são incorporados como rotinas padronizadas nesses softwares. Já na dé- 
cada de 90, os escritórios de gerenciamento de projetos passaram a atu- 
ar em múltiplos projetos e projetos cada vez mais complexos, impõe-se, 
então, a necessidade de desenvolver um gerenciamento global e atento 
as estratégias organizacionais. 


Crawford (2002), define que existem três níveis: 


Nível 1 - Escritórios de Controle de Projetos; 
Nível 2 - Escritórios de Projetos de uma área de negócios; 
Nível 3 - Escritório Estratégico de Projetos. 


Os escritórios de controle de projetos (Nível 1) atuam no controle de 
projetos grandes ou médios. São responsáveis pela emissão de relató- 
rios de progresso do projeto e de acompanhamento dos indicadores de 
desempenho estabelecidos. Normalmente, se encarregam de projetos 
únicos. As principais funções são: 


1) confecção e emissão de relatórios de progresso; 
2) confecção e emissão de custos e orçamento; 
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3) confecção e emissão de relatórios de gerenciamento de riscos; 
4) manter dados de ações históricas e lições aprendidas; 
5) confecção e emissão de relatórios de desempenho (performance). 


Os escritórios de gerenciamento de projetos de segundo nível atuam no 
controle de projetos grandes ou em número um pouco maior de projetos 
pequenos ou médios. 


As principais funções dos escritórios desse nível são: 


1) todas as funções do escritório de gerenciamento de projetos de pri- 
meiro nível); 

2) fornecer treinamento em gestão de projetos; 

3) estabelecer e verificar o cumprimento dos padrões e métricas de ges- 
tão de projetos; 

4) possibilitar o alinhamento dos projetos às estratégias do depto. ou 
divisão; 

5) controlar e armazenar as lições aprendidas e outros elementos e re- 
latórios gerados pelos projetos; 

6) padronizar ferramentas de gerenciamento; 

7) definir, implementar econtrolar mecanismos de controle de mudanças; 

8) assumir o papel de mentor para projetos com problemas. 


Os escritórios de gerenciamento de projetos (Nivel 3) atuam em nível 
corporativo. A equipe dos escritórios de gerenciamento de projetos ge- 
renciam o plano de ação corporativo e auxiliam os escritórios de geren- 
ciamento de projetos de níveis inferiores. 


As principais atribuições do escritório de gerenciamento de projetos de 
nível 3 são: 


1) padronização de gestão projetos; 

2) identificação, priorização e escolha de projetos estratégicos; 

3) assegurar e direcionar os projetos para a estratégia da organização; 
4) gerenciamento corporativo dos recursos; 

5) treinamento aos gestores de projetos; 

6) implantação e manutenção de um sistema de informações de gestão 


de projetos; 

7) desenvolvimento de planos de carreira dos profissionais de gestão de 
projetos da organização; 

8) desenvolver e divulgar as metodologias e processos de gestão de 
projetos; 

9) escolher e disponibilizar as ferramentas de gestão de projetos. 


Então, resumindo, a ênfase do escritório de gerenciamento de projetos 
deve ser em auxiliar o gestor de projetos, e não tomar para si o projeto. 
Para tanto, o escritório de gerenciamento de projetos tem como atribui- 
ções e responsabilidades: 


1) otimizar a utilização de recursos necessários para a condução dos 
projetos; 


2) reconhecer e disseminar a cultura de gerenciamento de projetos 
como uma disciplina distinta e com especificidade própria; 

3) prover uma organização estruturada para abrigar as habilidades es- 
senciais requeridas em gestor de projetos e para apoiar e incentivar 
o desenvolvimento de padrões e expertise; 

4) focalizar no desenvolvimento atual e futuro da gestão de projetos na 
organização; 

5) definir princípios e padrões de gestão de projetos; 

6) garantir a execução de projetos consolidados e unificados no conjun- 
to da organização. 


Leitura Complementar 


Para aprofundar os conhecimentos sobre gerenciamento de proje- 
tos sugiro a leitura dos seguintes artigos científicos que tratam dessa 
temática. 


PEMSEL, Sofia. WIEWIORA, Anna. Project management office a kno- 
wledge broker in project-based organisations. International Journal 
of Project Management. v.31, 2013, p.31-42. 


A pesquisa relatada neste artigo tem como objetivo examinar as fun- 
ções do escritório de gerenciamento de projetos a partir de uma 
perspectiva de compartilhamento de conhecimento e explorar se 
essas funções refletem ou não as necessidades de compartilha- 
mento de conhecimento dos gerentes de projetos. Essas questões 
são investigadas por meio de uma análise cruzada de casos de sete 
organizações. A principal contribuição é a percepção de como os 
gerentes de projetos compartilham conhecimento e passam a ter 
consciência da necessidade de estruturar os escritórios de gerencia- 
mento de projetos para se alinhar com a natureza, as necessidades 
e as expectativas dos gestores da organização. 


ARTTO, Karlos et all. The integrative role of the project management 
office in the front end of innovation. International Journal of Project 
Management. v.29, 2011, p.408-421. 


Este artigo tem como principal objetivo conceituar e analisar os es- 
critórios de gerenciamento de projetos de uma maneira mais am- 
pla do que apenas como uma unidade organizacional especializada 
com foco em projetos. Com base nas teorias de controle de gestão, 
design organizacional e literatura de inovação, avalia-se o papel dos 
escritórios de gerenciamento de projetos como um arranjo integra- 
tivo. Os resultados da pesquisa realizada mostram uma variedade 
de mecanismos de controle gerencial que podem ser considerados 
como arranjos organizacionais integrativos. A principal contribuição 
deste artigo está nos mecanismos organizacionais e gerenciais de 
uma empresa que gerencia múltiplos projetos de inovação. 
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JUGEND, Daniel. BARBALHO, Sanderson C.M. SILVA, Sérgio Luis 
da. Contribuições do escritório de projetos à gestão do portfólio de 
produtos. Production, 26(1), 190-202, jan./mar. 2016. 


Apesar de existirem muitos trabalhos sobre escritório de projetos 
e gestão de portfólio de produtos, são poucas as investigações que 
analisam esses elementos de maneira conjunta. Este artigo tem 
como objetivo identificar como o escritório de projetos pode con- 
tribuir com a gestão do portfólio de produtos. A pesquisa foi desen- 
volvida por meio de estudo de caso único em empresa de base tec- 
nológica que renova seu portfólio de produtos com alta frequência 
e que possui a estrutura de escritório de projetos bem consolidada. 
Dentre os principais resultados, notou-se que é maior a participação 
do escritório de projetos nas decisões de revisão de portfólio do que 
naquelas relacionadas ao planejamento estratégico de produtos e 
que essa estrutura presta apoio à alta administração e às equipes de 
projeto para a aplicação dos métodos financeiros, de mapeamento e 
de avaliação de fases ao longo das atividades de gestão do portfólio 
de produtos. 


CRUZ, C.. SCUR, G.. Alinhamento do PMO à Gestão Organizacio- 
nal: Estudo dos Elementos do PMO sob as dimensões estratégica, 
tática e operacional. Revista de Gestão e Projetos, v.7, (1), p.32-40, 
2016. 


O estabelecimento de um escritório de gerenciamento de projetos, 
Project Management Office (PMO), ajuda a transformar a cultura 
organizacional ao evidenciar, de forma estruturada, as necessida- 
des de processos e corpo de governança, gerando mais benefícios, 
disciplina e entendimento para a organização. O desafio de organi- 
zações orientadas a projetos não é somente a implantação de um 
PMO, mas qual tipo e onde alocá-lo na estrutura organizacional no 
que tange à autonomia e ao poder na organização. Nesse contexto, 
o objetivo deste artigo é identificar e descrever os elementos que 
contribuem para o alinhamento do PMO à gestão organizacional nas 
dimensões estratégica, tática e operacional. A revisão sistemática da 
literatura possibilitou a formação de um quadro teórico contendo 
principais elementos em cada dimensão que pode servir de guia 
para a prática da gestão do PMO ao estabelecer meios de melhoria 
da gestão de projetos e, por conseguinte, de gestão organizacional. 


ATIVIDADES 


1. Pesquise na internet por “estruturas organizacionais funcio- 
nais”. Resuma pelo menos um site e compare-o com o que foi 
visto neste capítulo 4. Responda a seguinte questão: Que novas 
percepções você adquire com esse site pesquisado? 


2. Pesquise na internet por “estruturas organizacionais matriciais”. 
Resuma pelo menos um site e compare-o com o que foi visto 
neste capítulo 4. Responda a seguinte questão: Que novas per- 
cepções você adquire com esse site pesquisado? 


3. Pesquise na internet por “estruturas organizacionais projetiza- 
das”. Resuma pelo menos um site e compare-o com o que foi 
visto neste capítulo 4. Responda a seguinte questão: Que novas 
percepções você adquire com esse site pesquisado? 


4. Pesquise na internet por “Project Management Office”. Resuma 
pelo menos um site e compare-o com o que foi visto neste ca- 
pítulo 4. Responda a seguinte questão: Que novas percepções 
você adquire com esse site pesquisado? 


GLOSSÁRIO 


Escritório de Gerenciamento de Projetos - EGP - Estrutura organizacio- 
nal estabelecida para facilitar as atividades da gestão de projetos e tra- 
zer melhorias ao próprio processo de gestão da organização por meio 
da gestão do portfólio e do alinhamento de projetos com a estratégia 
corporativa. 


Project Management Office - PMO - Termo em inglês para Escritório de 


Gerenciamento de Projetos - EGP. 
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CAPÍTULO V 


SISTEMAS INFORMATIZADOS 
PARA GERENCIAMENTO 
DE PROJETOS 


Prof. Ricardo Thielmann 


Objetivos Específicos 


O objetivo deste capítulo 5 é apresentar a importância dos sistemas in- 
formatizados para gerenciamento de projetos nos processos de planeja- 
mento, execução e controle de um projeto. Para isso, serão apresentados 
Os principais recursos necessários e desejáveis em um sistema informati- 
zado para gerenciamento de projetos. 


Introdução 


A informação, junto com a comunicação, é a essência do gerenciamento 
de projetos. Desde o início de um projeto, as informações são necessá- 
rias para permitir estimar os custos e os tempos, e é a precisão e facili- 
dade de aquisição destas informações que determinam a qualidade da 
estimativa. 


O sucesso de um projeto depende muito da aquisição, preparação, tro- 
ca, disseminação, armazenamento e recuperação de informações, e para 
que essas atividades sejam realizadas de forma eficiente é necessário a 
existência de um sistema de informação. 


Na literatura de gerenciamento de projetos, os sistemas informatizados 
para gerenciamento de projetos são considerados como essenciais para 
os gerentes de projetos, pois permitem um suporte para a elaboração 
do planejamento, da organização, do controle dos projetos, facilitando 
a emissão de relatórios e verificando o andamento das tarefas o que 
permite a tomada de decisão mais rápida e eficiente. Conforme definido 
por Cleland e King, a função básica de um sistema informatizado para ge- 
renciamento de projetos é fornecer aos gerentes informações essenciais 
sobre os parâmetros de desempenho de custo e tempo de um projeto e 
sobre a inter-relação desses parâmetros. 
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Segundo Berzisa e Grabis (2012) os sistemas de informações para ge- 
renciamento de projetos podem ser definidos como um conjunto de 
técnicas e ferramentas padronizadas e automatizadas utilizadas no ge- 
renciamento de projetos, para planejamento, execução, monitoramento 
e fechamento do projeto, bem como para coletar, organizar e distribuir 
informações sobre o projeto. 


Existe a necessidade cada vez mais presente de que as decisões tomadas 
nas atividades de projetos sejam ágeis e assertivas, em relação a um 
ambiente de mudanças constantes e volume de informação crescente. 
Então, a utilização de um sistema de informações para gerenciamento 
de projetos deve conter a capacidade de armazenamento de informa- 
ções do projeto, essencial ao planejamento e controle do mesmo, além 
de fornecer uma base de dados que permita determinar em tempo real 
a situação do projeto em relação a custos, cronograma e objetivos de 
desempenho técnico e de situá-lo dentro do contexto geral da estratégia 
da organização. 


Então, o objetivo de um sistema informatizado de gerenciamento de pro- 
jetos é prover uma estrutura para coletar, organizar, armazenar e proces- 
sar as informações do projeto. Com a utilização de sistema informatiza- 
do de gerenciamento de projetos, é possível gerenciar uma quantidade 
muito maior de informações em tempo real e com isso avaliar de forma 
mais assertiva e factual o status do projeto em suas diversas dimensões, 
sejam elas de ordem operacional, tática ou estratégica. 


5.1 Principais Características de um Sistema de 
Informações para Gerenciamento de Projetos 


Os primeiros pacotes de software de gerenciamento de projetos eram, 
principalmente, agendas eletrônicas utilizadas para a realização de agen- 
damentos das datas de início e término das tarefas. À medida que mais 
refinamentos eram introduzidos, os pacotes de softwares buscavam refi- 
nar o entendimento mais detalhado dos planos de trabalho, dos recursos 
e dos custos, tornando os modelos mais precisos. 


Existem diferentes sistemas informatizados para gerenciamento de pro- 
jetos disponíveis no mercado e que podem ser usados por qualquer tipo 
de organização e a escolha deste sistema dependerá fortemente do es- 
copo dos projetos que são desenvolvidos e das necessidades específicas 
desses projetos. Além disso, algumas empresas podem adquirir soluções 
sob medida. 


Portanto, dependendo da empresa e do tipo de projetos aos quais serão 
dirigidos, o sistema informatizado para gerenciamento de projetos pode 
variar significativamente. No entanto, é importante observar que todos 
os projetos incluem vários elementos básicos e que esses elementos se 
tornam requisitos essenciais de qualquer sistema informatizado para ge- 
renciamento de projetos: 


* Definição e detalhamento do escopo do projeto, que é o objetivo do 
projeto e inclui todas as tarefas necessárias para concluí-lo; 


* Alocação de recursos, para definir equipes e atribuições individuais, 
além dos materiais necessários para a condução das atividades; 


* Gestão do Tempo, que inclui a estimativa das durações das ativida- 
des e o posterior controle do cumprimento dos tempos definidos; 


* Gestão dos itens entregáveis; 
* Gestão das atribuições; 


* Gestão de riscos, para lidar com as incertezas e controlar o fluxo do 
projeto de forma eficaz; 


* Monitoramento; 
* Controle de qualidade. 


Pode-se elencar uma série de benefícios que a organização pode ter ao 
utilizar um sistema informatizado de gerenciamento de projetos, a saber: 


* os projetos podem ser gerenciados de forma integrada; 


* tarefas e atribuições de tarefas podem ser criadas, atualizadas e ras- 
treadas em tempo real; 


* a equipe do projeto tem acesso direto e em tempo real a todos docu- 
mentos relativos ao projeto; 


* os documentos são atualizados e apenas as últimas versões aprova- 
das estarão disponibilizadas aos membros da equipe. 


* a equipe do projeto tem acesso à lista completa de tarefas a eles 
atribuídas; 


* as tarefas são atualizadas automaticamente, quando modificações 
são necessárias, na programação realizada e todos os atores são in- 
formados imediatamente quando isso acontecer; 


* os membros da equipe do projeto podem relatar seu progresso em 
um ambiente comum, permitindo que outros membros da equipe 
entendam facilmente onde o projeto está em comparação com a li- 
nha de base do projeto; 


* | ocontrole de conclusão das tarefas acontecendo em tempo real, com 
a devida inclusão de justificativas para eventuais reprogramações das 
tarefas do projeto; 
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* os membros da equipe do projeto podem comunicar-se uns com os 
outros em tempo real. Todas as comunicações podem ser registradas 
e rastreadas de dentro do software. 


Muitas organizações, pequenas, médias ou grandes têm adotado os sis- 
temas informatizados para gerenciamento de projetos com o objetivo de 
aumentar a eficiência, a produtividade e a transparência em relação aos 
projetos que são desenvolvidos. Um dos aspectos mais importantes é 
a possibilidade de os gestores atuarem proativamente nas tarefas, caso 
os recursos estejam atrasados, aumentando as chances de o projeto ser 
concluído no prazo e com rentabilidade. Isso é particularmente verda- 
deiro para empresas que executam vários projetos ao mesmo tempo. 
Além disso, o uso de um sistema informatizado para gerenciamento de 
projetos torna-se essencial quando as equipes são compostas por pesso- 
as que estão dispersas em vários locais, porque fornece a elas acesso a 
um banco de dados de informações centralizado que reflete atualizações 
em tempo real. 


A figura 1 apresenta as principais funcionalidades básicas necessárias 
para um sistema informatizado para gerenciamento de projetos. 


Item Funcionalidade Área do Fase do ciclo de 
Conhecimento vida do projeto 
1 TERMO DE ABERTURA DO INTEGRAÇÃO Iniciação 
PROJETO 
MATRIZ DE RISCOS RISCOS Iniciação 
3 |WBS ESCOPO Planejamento 
4 | CONTROLE DE ALTERAÇÃO ESCOPO Execução e 
DE ESCOPO Controle 
5 | CRONOGRAMA DE PROJETO | PRAZO Planejamento 
6 | BASELINE DE PRAZO PRAZO Planejamento 
7. | TAXAS DE RECURSOS PRAZO Planejamento 
8 | CONTROLE DE CUSTOS CUSTO Planejamento 
9 | BASELINE DE CUSTOS CUSTO Planejamento 
10 | EVM CUSTO Execução e 
Controle 
11 | LISTAS DE VERIFICAÇÃO QUALIDADE Planejamento, 
Execução e 
Controle 
12 | AUDITORIAS DE QUALIDADE | QUALIDADE Controle 
13 | MATRIZ DE QUALIDADE Planejamento e 
RESPONSABILIDADES Execução 
14 | INDICADORES DE QUALIDADE Planejamento, 
QUALIDADE Execução e 
Controle 
15 | ORGANOGRAMA DE RECURSOS Planejamento e 
PROJETO Execução 
16 | HISTOGRAMA DE RECURSOS | RECURSOS Planejamento, 
Execução e 
Controle 


17 | RELATÓRIOS DE COMUNICAÇÕES | Execução e 
DESEMPENHO Controle 
18 | CURVAS DE AVANÇO FÍSICO | COMUNICAÇÕES | Execução e 
Controle 
19 | CURVA DE AVANÇO COMUNICAÇÕES | Execução e 
FINANCEIRO Controle 
20 | LISTA DE PENDÊNCIAS COMUNICAÇÕES | Execução e 
Controle 
21 | REGISTRO DE RISCOS RISCOS Planejamento 
22 | REGISTRO DE RESPOSTA A RISCOS Planejamento 
RISCOS 
23 | AUDITORIA DE RISCOS RISCOS Execução e 
Controle 
24 | LIÇÕES APRENDIDAS INTEGRAÇÃO Finalização 
25 | NOTIFICAÇÕES COMUNICAÇÕES | Execução e 
AUTOMÁTICAS DE E-MAIL Controle 
26 GERENCIAMENTO DAS INTEGRAÇÃO Planejamento, 
DOCUMENTAÇÕES Execução e 
Controle 


Figura 1 - Relação de Aplicações necessárias para um sistema informatizado para gerenciamento de 
projetos. 
Fonte: Elaboração própria a partir do conteúdo do PMBOK, 2020 


5.2 MS Project 


O Microsoft Project é o software de gestão de projetos da gigante de tec- 
nologia Microsoft. Ele é uma das ferramentas de gestão de projetos mais 
antigas do mercado: sua primeira versão foi lançada em 1985, A interfa- 
ce deste software se assemelha com o Microsoft Excel. Ele também utili- 
za o gráfico de Gantt como forma de organizar o cronograma do projeto 
e permite atribuir tarefas para os participantes. Além disso, o MS Project 
permite ao responsável pelo planejamento, execução ou controle de uma 
série de atividades que se relacionam, trabalhar alinhado à utilização de 
recursos, custos, cronograma e as principais áreas do gerenciamento de 
projetos, segundo o modelo proposto pelo PMBOK. 


5.3 Trello 


Uma das ferramentas de gerenciamento de projetos mais famosas do 
mundo, o Trello utiliza um esquema de listas, cartões e quadros para or- 
ganizar atividades dentro de um projeto. Ele funciona basicamente como 
um kanban e sua principal vantagem é a facilidade de movimentar as 
tarefas entre as listas do projeto, além de permitir a utilização de boots 
para realizar tarefas automaticamente. Entre as empresas que usam o 
Trello temos o Google e o Pinterest. 
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5.4 O Primavera 


A Oracle Primavera foi desenvolvido para ajudar as empresas que traba- 
lham com muitos projetos a gerenciar todo o ciclo de vida do portfólio 
de projetos, independentemente do tamanho do projeto. As soluções 
de última geração fornecem os recursos de execução e controle de pro- 
jetos necessários para fornecer projetos com êxito, no prazo, dentro do 
orçamento e com a qualidade e o design planejados. Compreendendo 
soluções setoriais para óleo e gás, engenharia e construção, fabricação, 
indústria aeroespacial e de defesa e setor público, o Primavera conta 
hoje com mais de 75.000 clientes em todo o mundo. suas principais 
funcionalidades são: 


* Seleciona o conjunto de portfólios estratégico adequado; 


* Planeja, programa e controla todos os projetos, incluindo programas 
de grande escala e projetos individuais; 


* | Aloca os melhores recursos e rastreia o progresso com base em ha- 
bilidades e disponibilidade; 


* Rastreiao progresso do projeto e monitora o desempenho do projeto 
em comparação ao plano; 


* Faz a integração com gerenciamento financeiro e outros aplicativos 
de software empresariais; 


* Faz o gerenciamento de portfólio: prioriza programas e projetos e 
otimizando a capacidade organizacional; 


* Fazo gerenciamento de programa: melhora a produtividade e a velo- 
cidade para produtos com visibilidade empresarial; 


* Fazo planejamento e a programação: executa os projetos mais com- 
plexos com facilidade; 


* Faz gerenciamento de recursos: combina pessoas e projetos. 


5.5 Artia 


É um software de gestão integrada em projetos, permitindo uma rápida 
comunicação entre as partes interessadas do projeto. O mesmo é usado 
por empresas conhecidas como a Embratel e a Unimed. Dentre as ferra- 
mentas presentes nesse software estão: Desenvolvimento do cronogra- 
ma do projeto, Exposição do Kanban de tarefas, Acompanhamento de 
horas e desenvolvimento de indicadores das mais diversas áreas como 
custo, riscos, entre outros. 


5.6 Slack 


O Slack promete centralizar toda a comunicação da sua empresa através 
de um software de chat e compartilhamento de arquivos. Ele é muito es- 
colhido para gerenciamento de projetos porque permite organizar con- 
versas através de canais, assim você pode manter chats com os stakehol- 
ders de cada projeto além de integrar diversos outros softwares. 


5.7 Podio 


O Podio permite organizar prazos de entrega, tarefas e arquivos em um 
só lugar. Todos os envolvidos no projeto conseguem visualizar o que está 
sendo planejado, em progresso e completo. O Podio ainda disponibili- 
za vários filtros para verificar, por exemplo, as entregas que uma única 
pessoa fez. Ele é usado por empresas como: Volvo, Deloitte, NFL, Sony, 
entre outras. Outra função bem interessante do Podio é a de armaze- 
nar o histórico dos antigos projetos para que possam ser usados como 
referência do que deu certo (ou errado). Essa ferramenta de gestão de 
projO Slack promete centralizar toda a comunicação da sua empresa 
através de um software de chat e compartilhamento de arquivos. Ele é 
muito escolhido para gerenciamento de projetos porque permite organi- 
zar conversas através de canais, assim você pode manter chats com os 
stakeholders de cada projeto além de integrar diversos outros softwares. 


5.8 Asana 


O Asana reúne várias funcionalidades para a gestão de projetos como o 
kanban, atribuição de tarefas aos participantes e exibição das estatísticas 
do progresso do projeto, além de uma versão Mobile (para celular). Mas, 
seu grande diferencial é na visualização da linha do tempo do cronogra- 
ma, através desse cronograma os participantes têm clareza de quais tare- 
fas precisam ser feitas para desencadear outras. É usado principalmente 
por startups como Nubank, 99 taxis e Spotify, mas também possui seu 
espaço em empresas mais tradicionais como a Danone e a Airfrance KLM 
Group. 


ATIVIDADES 


1. Faça uma busca na internet por “Sistemas Informatizados de 
Gerenciamento de Projetos” e escolha três sistemas encontra- 
dos. Faça um resumo sobre as principais funcionalidades dos 
sistemas escolhidos. 


2. Faça o download de uma versão de testes de um sistema infor- 
matizado de gerenciamento de projetos e responda às seguintes 
questões: a) Que sistema você escolheu? Quais os principais 
recursos ele contém? 
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